The database action insert now seems to be synchronous returning _id right after the insertion, therefore no callback is needed here.
The question lies on where does the _id being generated (and checked), since this seems to be a fast synchronous action done on miniMongo, yet there is no full list of _id of a certain collection, how’s that possible for miniMongo to check whether the _id is duplicated or not??
When using Collection.insert on the client, the _id is generated on the client using a random uuid algorithm, hence the seemingly perfectly latency compensated client-side insertion.
Collection.insert being implemented as a special case of Meteor.method, we know that at the same time the client simulation is run on the client, a corresponding server operation is triggered, the client document is sent to the server along with its locally generated _id.
On the server, there's a check to see if the _id is correct (truly unique) and the server acknowledge the valid insertion back to the client.
If the client generated _id was not unique after all, then the insert will fail with a "duplicate key error" (this could happen like 0.001% of the time - the probability is even lower, and you would have to resubmit your client form or whatever).
To answer specifically your question, the _id can be generated in the browser in case of a client insert, but it's validity is ultimately checked on the server.
EDIT : I initially assumed that Meteor was trying to recover from the duplicate key error and generate a new key to avoid duplicity and propagate it on the client, I tested the use case and found out I was wrong, thanks @Tom Freudenberg for pointing this out.