First, I want to say that I don't think we need trust/reputation and even account names on every DAC. In my view we should keep the account names and the trust/reputation of an account on a single DAC: BitShares DNS. Other DACs should simply refer to the DNS DAC when determining the Account Keys and reputation of an account from a human-readable account name, just like they would have to refer to the DNS DAC to get the IP address and public keys of a .p2p domain.
Okay, that still leaves some trust/reputation mechanisms needed for KeyID accounts. Agent86, I think your proposal is pretty decent, but I have some concerns. First, I don't like that someone needs to wait 30 days to get a novel account name set up. That is putting up unnecessary barriers for new users in my opinion. And, there is already a great name system with a proper auction for names that we want proper discovery on: the .p2p domains. As for KeyID names, I think if someone picks a new account name and people don't think it should be registered, it will be killed by negative devotion fairly quickly anyway (since lifetime would be very small by the time people realize the name was registered). If an account name has been killed, then we can require waiting 30 days before it can be re-registered. During that time you can have people competing with the devotion mining as in your proposal.
By the way, I want to make the quick side remark that I am not very bothered by the idea of account names dying and being reclaimed. Your robohash patch is clever, but I don't even think that is necessary. I personally never liked the robohash idea to begin with (it looks too unprofessional). I would rather rely on adding accounts I communicate with or send money to in my favorites and use that to warn me against typos. And if an account died and was re-registered, the client could automatically warn me when that happens to any of the accounts in my favorites. In the case of adding new contacts to favorites or sending money to a contact not in my favorites, since this is an unusual event, I think relying on registration date and trust level should be enough to prevent mistakes (if the client GUI is designed properly that is). Also with our own version of BIP 70, payments to merchants would be secured with their .p2p name not their KeyID name.
The second concern I have is regarding privacy. While people can use their coin-age to add or subtract devotion of any user. I bet that it is going to be far more likely that any positive devotion is going to be to their own accounts. This links the balances of the user together to their account. And even that wouldn't be such a problem if it wasn't for the fact that you really should use your coin-age to boost your devotion to protect your account from the trolls. I wonder if there can be a technical solution to this using linkable ring signatures (or whatever BitShares Vote is using). You could use signatures to prove ownership of balances that have already been transferred but not yet claimed as coin-age. The sum of the claimed coin-age is rounded down to the nearest N*c coin-age (where N is an integer and c is some fixed coin-age constant). This entitles the recipient to N coin-age votes. Then using linkable ring signatures, the user can disassociate the N coin-age votes from the original signatures granting access to the coin-age votes, and use each of the disassociated coin-age votes to either add to or subtract from any account's devotion. A lot of complication for the sake of privacy. Not sure if it is worth it.