Seconded. This is the standard CouchDB approach: one database per user.
Sounds weird coming from my Postgres and MySQL background, but works great in practice, depending on your use case and if you clear out old revisions and unused docs, which for our use case can number into the thousands fairly rapidly.
Everything in software is a trade-off. This trades space efficiency for multi master replication with first class offline app experiences.
For many cases, that's a fine trade. Disks are cheap. If that isn't a fine trade for a particularly large dataset, use a different technology that's better at space efficiency and worse at other stuff.
This sounds _nuts_ from a traditional database mindset, but works great in Couch.
You can then create another database that replicates from all the user databases in order to perform your aggregate queries on the back end.