Best practice here is the same as for all databases, that the primary key should either be related to a physically unique value, or generated by the client. This is true for any database technology. The reason to do it this way is that it allows you to be relatively failure proof, so that it is okay to retry any insertion and not worry that you will end up with duplicate values.
We do not currently have an auto-number option, though it is possible we will get one, but my advice is to avoid it if at all possible.
Why do you want the id to be an int or uint?
When I have done this in the past, I have used a client identifier prefix, with a numeric suffix. This avoided the problem of clashing keys between clients who knew nothing about each other.
If there is no other way, and you need server keys, then the best way is to use a stored query which can manage transactional updates to a central counter held on a stored “Counter” vertex, but performance (due to locking and synchronisation overhead) will be much less than the previous options.