Since you say distributed generation is a requirement I'm going to argue for UUID. version 1.
the number must be fairly easy to remember and must say something about the time (or at least sequential order) the order was placed. This eliminates things like UUIDs as an option, since those are both very hard to remember and lack any time information.
UUID Version 1 has time information. It also has what you call
another few random digits to significantly decrease the chances of a collision.
I think we can do better than simple random here. Being unpredictable isn't a requirement. Being unique is. A unique location ID takes away any chance that another site in your distributed system collides with this one simply because they aren't communicating. If your system is on a network you already have a unique location ID in the form of a MAC address.
That leaves issues with time. Time is not a simple thing. Nothing measures it perfectly.
To resolve this what I think you need is the Clock Sequence (p8). In UUID v1 this is a 14-bit unsigned integer that is incremented or randomized whenever something goes wrong with the clock. When that happens you essentially get a "new clock" or at least a new ID for one. This prevents the resetting of the system clock from causing collisions. Every reset is a new clock.
You might be thinking UUIDs must be presented in a form that looks like this:
ietf.org - rfc4122
Which is hardly memorable. But it could be presented like this:
realityripple.com - UUID Decoder
Which is far more human readable. If that's not enough you could sacrifice robustness and scale down the MAC address and sequence number to make them more human readable. This takes you away from the UUID specification but you understand your system far better than the UUID people did so you can do things like name your distributed locations after fruit.
As for your sequential requirement understand that the clock itself puts an ordering to these. One that would require adjustment when distributed clocks aren't synchronized. That will be an issue in any distributed system that doesn't communicate to synchronize. You can make the system synchronize the clocks or do it after the fact. "Yeah Apple is 5 minutes faster than Banna".
You can also adjust the precision of the clock if you'll give up the bits needed to record to the second, millisecond, or nanosecond. Whatever precision you set determines how often you can issue an ID.
Or you can simply increment a counter field when issuing more than one ID each second. That only works when you don't care about ordering within a second across distributed systems. If you do, and want to stick with seconds, your only choice is to delay issuing the ID until it has its own second to be issued in.
There is no level of clock precision that will prevent two sites from issuing IDs with the same time, or with the same random. If this is a problem and order is important you may as well reach for more clock precision rather than more random. But as you reach into the nanosecond range there starts to be little difference between them.
This can be trimmed down to be more memorable if your requirements allow. Maybe you don't need them to memorize the date in the time stamp because these numbers are only outstanding for one day. Maybe the distributed systems communicate so they can simply count up unique numbers even as they are issued remotely.
However you do it, I think studying how UUID solves this problem in the general case will at least point you to a reasonable design that solves your specific case.