Yes, you can do this and it can work fine in assorted situations, though not in all.
If you have the case you have described, where each always works on a different database, life is very easy and it'll just work, no more reading required.
Otherwise here are two major issues to watch for:
1. You must have some method for ensuring that the primary keys of the records can't be reused at the different locations/servers. That is, you need to make sure that both don't store different data with record ID 1, say.
2. You must have some way to ensure that both servers aren't updating or deleting the same record at the same time. There is no built-in support for this, though GET_LOCK() is one function which may assist, using it to lock on the server where the record is not being actively changed. The timeout can ensure that you don't stall forever if the server is down.
For 1, one way is to use the autoincrement_increment and autoincrement_offset settings to cause each server to use a different range of autoincrement values for a primary key. This tends to be ideal for applications which just expect autoincrement and then may not need any modifications to just work. These settings are described at
http://dev.mysql.com/doc/refman/5.0/en/replication-auto-increment.html "6.13. Auto-Increment in Multiple-Master Replication".
Another way is to use GUIDs, though is often inefficient with InnODB.
Alternatively, you can use only one at a time for the changes but both for queries. This eliminates the uniqueness and locking issues.
Coming in the future is support for conflict resolution on the server when a conflict between updates from two or more servers are identified. The delivery date for this looks likely to be in the next 8-18 months though that is not guaranteed.
James Day
Support Engineer, MySQL AB