Using schemas gives you imperfect but still improved isolation. It's still possible for a database connection to cross into another tenant, but if your schema search path only includes the tenant in question, it significantly reduces the chance that cross-customer data is accidentally shared.
I think numeric ids should be allocated out of the same key space, other identifiers should be hierarchical and scoped to the tenant in the database.
The same query run across all databases should either return 1 query (for the valid tenant) and empty set for all other databases, OR it should return the same result set regardless.
I just realized what I am proposing, a hidden out of band column that is effectively the "database id" for that row.
If you built a tenanting library that used partioning rather than schemas, you'd probably end up with something that looked pretty close to what you're describing.
With schemas, it's definitely possible to use the same generator for ids across schemas (at least, I'm 90% sure it is in Postgres), but you'll probably end up fighting against ORM libraries to get it to work properly (Rails for instance makes a LOT of assumptions about how the id column works), and you aren't technically guaranteed uniqueness since you'll still have distinct PK columns.