I would rather get rid of account names entirely than keep them non-transferable. But keeping transferable account names shouldn't be an issue if we design things right and teach users sensible practices.
tl;dr Just use account IDs for everything (especially for links on the internet and referring to identity in third-party databases). The only time account names should be used is to add a new contact to your address book that you were not able to add through better means such as trusted web links or mobile-to-mobile communication. The GUI shouldn't allow the user to do anything of value with an account unless they are first added to the address book (perhaps even added automatically to some obscure part of the address book because of some action where the smartphone is interacting with the real world, for example for POS payments). Adopting these practices should deal with the vast majority of the issues. What remains are edge cases dealing with what happens when a contact changes their account name after telling you their account name but before you have the opportunity to add them to your address book. Those cases can be handled through changes to the GUI of the client and proper education on how to use the client.
The first thing to realize is that if you want to allow account owners to be able to update all private keys associated with their account for
security reasons, then it is impossible to prevent account names from being transferred. The current owner could just sign a transaction using the current owner key changing the owner key of the account to one specified by the buyer of the account name. Yes, all identity information would be transferred along with the account, but a name squatter buying valuable names for the purpose of later selling them isn't going to care about that. The security benefits of changing the owner key are very important that I would say it outweighs any other concerns about identity you may have when account name becomes transferable.
So once you accept that you cannot avoid allowing account names to be transferred, you might as well make it possible to transfer the account name without also transferring all the other identity information. In fact, there needs to be a clear separation between an identity and an account name. That brings me to my main point...
Your account name is not your identity! Your identity is your account which can be uniquely and immutably referred to by the account ID. This is the thing that can be stored in third-party databases, NOT the account name.
Now that is fine for computer databases, but human brains aren't good at remembering large numbers. So clearly people would prefer to instead remember a human readable account name over an account ID. How do we avoid the human error this can cause when we consider that the name of an account can change and the old name can belong to another account (meaning another identity)? The solution is for humans to not try to rely on their memory but rather rely on computer databases. The mapping between the human-understandable information describing an identity to a unique account ID should be local to each user. This is the information that will be stored as part of the wallet file (which is stored in the browser's local storage, but can also be exported and backed up elsewhere). In fact, I think it would be smart for the wallet hosts to provide a service where they store an encrypted version of the wallet file for the user and sync it as necessary to their clients. The point is that the mapping is local to each user and not global on the blockchain. This means that every user can specify the alias (and even picture and other information) that helps remind them who that contact in their address book really is. None of this requires any global blockchain name registration or management.
However, with all of that said, name registration on the blockchain is useful. Particularly, it is useful as a method to allow humans to add new contacts to their address book when the only way they are able to refer to the account is through a uniquely-identifying string/number that they are forced to remember. The context through which they came to know or meet this new contact may not have facilitated using better methods of adding the contact right then and there, such as direct mobile-to-mobile contact sharing or clicking on an add contact link from some trusted web source or even scanning a QR code with their smartphone that was presented to them in person by the contact. Perhaps they didn't have their smartphones or didn't have time to use them and the contact quickly shared the uniquely-identifying string/number before leaving. Perhaps this string/number was shared over a medium where the validity of the source could be readily verified thanks to biometric authentication or trust in the provider of the media, such as a well-known guest with recognizable voice on an audio podcast saying and even spelling her handle, a video podcast showing the respective handles of guests whose face people can recognize in the lower third overlaid when they are on camera, a presenter that people know displaying their handle in his slides during a live lecture, or just simply the new contact they meet telling them the handle in person. Now the number could just be the account ID or the string could be a sequence of dictionary words encoding the account ID (+ a checksum), in which case name registration is again not necessary. The problem is that since the user is not able to choose their account ID (and thus the deterministically derived string of words representing the ID either) it might still be difficult for humans to remember them (although the sequence of dictionary words encoding the account ID trick does get pretty close to being memorable). Also, from a vanity point of view, users may wish to have their own choice of the string that they present which will map to their account ID even if faulty memory wasn't that big of an issue. This leads us to registering globally unique account names on the blockchain and mapping them to account IDs.
So that is when all the various edge case problems come in that need to be dealt with. If a person registered the account name once and never changed it, there would be no problem other than typos and misspellings which could be solved by also remembering, sharing, and including a small easy-to-remember number that acts as a checksum. And once a user adds a contact into their address book using their handle, their client should be designed to protect them from account name changes because it can remember the immutable account ID of the contact locally (and this local data should be backed up with the rest of the wallet). The tricky part is in the case where the contact changes their account name in between the time the contact veritably shared their original account name in a way that the user could access and the time the user added that contact using the original account name that they remembered. Even this is not an issue if the old contact name is not transferred to or claimed by any other account before the time the user adds the contact since the client would respond to the user that the account name is not currently being used and could show the past history of ownership of that name. What we really want to avoid is another account adopting the old name before the user adds the contact using the old name causing the user to add this other account instead of the original account. But the blockchain tracks when account names are created, moved, revoked, and adopted, so this information history could be made available to the user's client. If the account name provided had recently (this could be a wallet adjustable setting but a default of two weeks seems like a good idea) changed ownership, the client can show massive warnings to the user, provide detail, and require further action before proceeding. The information provided would allow the user to determine which of the accounts they meant to add depending on when they got the information about the account name. This is an edge case, so usually these warnings would never appear since the account name would have most likely not been recently moved. As long as the user is not adding an account name from a very old source, they should be fine. If they do want to add an account name from an old source (more than 2 weeks old for example), the client could provide an advanced interface allowing them to specify a date to determine the ID of the account that owned that name at the date. Since I believe the use case for adding contacts using their account name should mostly be for in person interactions where smartphone contact transfer was not applicable, or live radio or TV, I don't think this will be a problem. If someone is consuming old recorded media, it is probably a better idea to not trust that handle and instead try to find the handle of the person they want to add from a more recent source just to be safe. And in the case of consuming the handle from an online source, the best practice would be for the website to just include links that point to the account IDs directly to just avoid these problems.