You say you cannot allow the number of bits a UUID spans. Is that a hard constraint, or is that an intuitive desire? in my experience limiting the number of bits is usually to fit on a single machine or in limited memory. However designing a distributed id system is all about scale and minimizing complexity from my point of view.
When you start to scale out to dozens of machines, the weight of these complex methods really starts to become evident.
I resisted UUID's for a long time, but I finally gave in, and you know what? It's one of the best decisions I've ever made. The design simplicity with v1UUID's is amazing. With the simple_uuid ruby gem I can generate 40kish UUID's per machine on a modest ec2 instance. Using NTP our clock drift is in the 10s of microseconds range IIRC. Using Cassandra and Hadoop we don't have to worry as much about fitting into a single machine. The overall improvements have been staggering though. The simplest and most important benefit is none of the services have to read or request information before generating an ID. Now it's generate an id, send the event on it's way, next. I'll leave it as an exercise for the interested reader to map out the synchronization process for generating unique id's without locking across multiple threads and multiple machines.
tl;dr Just use version 1 UUID's and NTP.