On a web app, user A gets a page, then user B gets a page, then user B submits a change, then user A submits a change. Unless you're doing some craziness that'll really kill performance, last in wins.
If that's acceptable, is it because it's unlikely two users would be changing the same data concurrently? If so, you could fake multi-master replication in the DB layer. Have all updates handled through stored procedures, and have every update proc fire the update to multiple other DBs after it commits. Do your framework properly and programmers don't need to think about it.
There are probably numerous reasons this won't work, but it's all I can come up with that I haven't already seen done.
[edit]
Bah, just saw that consistency is key. Can't rely on "usually not a problem" in those cases. But would it be true often enough, and would the performance boost be great enough, to make it worth trying?