Wow, excellent idea.
What if you enhanced it as follows:
1 - find some other way for the parties to communicate other than Namecoin. What if all the mixing nodes (which are software bots, of course) just hooked up with one another in an IRC channel and communicated in real time?
2 - have three rounds so that the participants at the beginning of the round aren't disadvantaged. During the first round, participants pass around bogus inputs and payout keys. During the second round, participants add the real ones to the bogus data set, which will look indistinguishable from the bogus ones, which prevents the second participant from knowing which real keys belong to the first etc. During the third round, participants remove the bogus data they added to the set.
Parties A,B,C,D,E,F get together in an IRC channel and all agree to start mixing. They each generate an RSA keypair. Let's assume the parties will speak in order, though ideally a simple deterministic hashing scheme based on their public keys could randomize the order (assuming they hash-commit to their public keys first).
All parties throw out their public key for everyone to see. From then on, messages are encrypted for their intended recipient unless otherwise noted.
Party A chooses 100 random unspent txids from the block chain (that are probably not his), and generates 100 bitcoin addresses. Basically he is creating a false claim that he wants to mix those coins to camouflage the coins he's going to add to the dataset in a future round. At the same time, he creates a random mapping of how he'd supposedly like those 100 txids to be paid to his bitcoin addresses. He sends the whole thing to B. (Actually, he could add any number of each, but I'm using 100 for simplicity).
Party B does the same thing, adds his data to the set generated by party A, and sends it to party C.
Same thing, to party D, then E, then F. When F sends it back to A, there should be 600 txids and 600 bitcoin addresses.
Round 2: party A adds the txids of the real coins he wants to mix, and new payout addresses to receive them, and sends them to B to do the same. Then it goes to C, D, E, F, and back to A.
Round 3: Party A removes all of the bogus information he added in round 1, sends it to B. Then C,D,E,F, and when it gets back to A, only the real information should remain.
Party A announces the proposed transaction publicly. Each party confirms that the mixing will result in them getting the same number of coins they put in.
If all parties agree to the transaction, they generate the signatures. They also generate a bunch of bogus placeholder signatures, so they can exchange signatures without divulging e.g. how many real signatures they are delivering.
To exchange the signatures, they encrypt them repeatedly, onion style (think Tor), so they must be passed back and forth among participants in multiple rounds to unpeel the layers. They are passed back and forth in random order, so no participants can identify the originator of any particular signature.
If one party doesn't agree with the proposed transaction (for example it omits a payout and shortchanges him), he generates all bogus signatures and no real ones, so his refusal to sign doesn't identify him to the person who altered the transaction to withhold his payout.
Once somebody/anybody has all the signatures (and the bogus signatures thrown out), the transaction is signed and broadcast.
During all rounds, outputs can only be specified in the following amounts of BTC: 1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, etc. Also, 0.5, 0.2, 0.1, 0.05, 0.02, 0.01, 0.005, etc.... this uncouples the outputs from the inputs. Otherwise, the guy who added 17.43233 BTC to the mix is probably the same guy with the 17.43233 BTC output.