I'm hearing about a lot of players - two or three a day - getting kicked out of the game. No clue if it's a bug, computer issue, whatever, the game crashes and they're out. Then they try to get back in and inevitably face several rounds of "this account is already logged in" (no, I don't remember the exact message). There is a solution for this. Not sure if the Developers would take my suggestion or not, but here it goes: Public Keys (The cryptographic kind). (This description is long, but this stuff is all old hat, easy for seasoned programmers.)
Each game client at first startup generates it's own Public/Private key pair, and the Public Key is stored with the user's Login Information. When the game client starts, it sends a request to the server, along with the Login request, for the server's Public Key. It uses that key to encrypt a random number (a 'nonce'), then encrypts it again with it's own Private Key. It sends that encrypted nonce to the Server, requesting a token. The server validates the login, then decrypts the nonce using the client's Public Key (from the user's stored login info), then it's own Private Key. Then the server uses the Public half of it's own key pair to encrypt a token specifically for that login. The server would store the login account name, time, valid time (length of time the token is valid), then generate a unique identifier pointing to that information. It then encrypts the Unique Identifier with it's own Public Key, adds the Nonce it got from the client and the Valid Time, Login Time, etc., encrypts that whole package with it's Private key and sends it to the client. Since it's own Public Key was used for the identifier, it can only be decrypted by the server's Private Key - the client can't modify it without the server rejecting the whole thing. This takes less than a second of computer time, and the player's game loads as normal.
When the game client gets the package, it uses it's Private Key to decrypt it. It checks the Nonce, and if it matches, the package is valid (if not, it will request it again). The game loads normally, while a process keeps an eye on the Valid Time. (This would have to be determined by the server developers - something short enough to keep players current, but not so short that it puts any real load on the system.) Say, for instance, the Valid Time is 10 minutes. The client adds that 10 minutes to the receipt time, and when the new time approaches (say 30 sec. out), it transmits that whole package again, asking for an updated token from the server. Wash, rinse, repeat until the client logs out normally.
Provided everything runs smoothly, nothing else happens. But if the client should crash, "lag out" due to internet issues, or just get stuck (unresponsive), when the client restarts, it looks for this package and checks it for validity. If it's out of date or invalid any other way, it's discarded. If it's valid and still within the time frame, it sends that package to the server instead of the token request during login. If the server also validates that token, then it can take action to get the player in, even if the account is "still logged in".
Having no clue how ESO handles adding characters to the server, connecting the clients, etc., I have only the slightest hope that the server could reconnect the client to it's former instance (extremely doubtful). More likely they'd just have to trash the old instance all together, instantly, and log the 'new' client in. This is probably the sticking point. If you aren't familiar with Public Key Encryption and Secure Key Exchange you might think all the encryption stuff is complicated enough to sink the whole idea. But it's really all solved problems, easy stuff with minimal computing overhead. The developers would just have to add the glue to get it to work with this game. Getting the client back into the game without "already logged in" messages... That is where this idea will either succeed or fall flat on it's face.