Presumably this is after not taking your own advice of performing AES256 encryption on the key before sending it to the user?
Your three easy steps together seem a lot more complex than just using guids.
I've never understood arguments against guid's, except for table performance with databases that might take a performance hit because of either inserts, or because data won't necessarily be partitioned in the "correct" order (e.g. MySQL writes to buffer pools).
...and then you proceed by suggesting ID code generation methods that replicate UUIDs.
It sounds like you are trying to criticize UUIDs while being totally unaware of what UUIDs are.
I mean, UUIDs are nothing more than integers that are generated following one of half a dozen different methods so that they can be probably unique without relying on a central authority.
One of the UUID versions is a pure random number. Another is a MAC address concatenated with a timestamp complemented with a local counter. There are literally two UUID methods that consist of hashing data.
Your supposed solutions to the alleged problem posed by UUIDs is a reinvention of what UUIDs have always been. But UUIDs have been though through and are standard and ubiquitous.
IMO that's a big advantage for integers that uuid's will never be able to overcome. Key size matters when you are dealing with heavily indexed data.
#1 Integer keys have finite range.
#2 Integer keys betray the identity of other sensitive resources when exposed as a public identity.
#3 Integer keys are "difficult" to sequence in the face of multiple networked participants.
My resolutions and counter-arguments are as follows:
For many systems, #1 is not a concern, because the number of expected entities is well-bounded by a 64 bit integer. For others, #1 can be resolved by usage of more complex types such as BigInteger (C#). If utilized carefully, these can be treated just like normal integers, and quickly converted to/from byte arrays of appropriate length to satisfy the required range. In virtually all SQL implementations, blob columns containing these values can be indexed with the exact same semantics as with a 64-bit integer column. Whether this performs better or worse than GUID keys probably depends on if you can provoke a >120 bit BigInteger representation. This is quite unlikely, even for Google.
#2 is trivially solved by simply applying encryption to sensitive keys as they traverse the boundary between your system and the outside world. AES256 would do the trick here. You could also generate entirely separate keys of any appropriate type for public consumption (i.e. maybe some YT-style identifier format).
#3 is solved by anticipating the maximum possible # of nodes in your system, and then producing a key space in which identities are sharded out by a simple constant factor of that max quantity. This would certainly produce concern regarding all of the skipped identities (assuming you start with a small number of hosts on day 1), but the proposed resolution above for #1 (BigInteger) alleviates these concerns with a practically infinite range of keys. Skipping 10k identities is a non-event when you have all of infinity to pull from.
There are also other considerations with this. GUID keys are a pain to communicate. Integers, even of massive range, are easy for most humans to communicate verbally when appropriate digit grouping and other reasonable measures are undertaken.
Also consider a situation in which you decide to use 1 global integer range to key every single entity in your system. This allows for interesting database structures in which foreign keys are all referring to the same keyspace, so the specific type of a thing is no longer a hard constraint in a relational sense. Some would probably take substantial offense to this proposal, but I have found in many cases this allows for powerful optimizations. Anything can be used irresponsibly.