I could be of assistance. I have experience with login GUI and that like. But, my knowledge is.. much more.. TGE based, i don't know the names and Controls of the T2 gui shells but it wouldn't be to hard to figure out. If Nao is unavailable just let me know.

The login screen contains a drop-down menu to select an account that is present on the system. The accounts present on the system are based on the public/private keypairs stored on the system.

The password field can remain as is. However, since there is no way to securely store the password on the system without allowing for potential compromise, I would remove the "remember password" option.

The "Email me my login info" should be replaced with a button labeled "Retrieve Stored Login Key From Auth Server". This will pop up a menu asking the user to select an authentication server, entering a username, and entering the password. This will download an encrypted keypair from the authentication server that is added to the list of available accounts.

The "Edit account" button can be removed.

The "Login" button, "Create New Account" button, and "Quit" button can remain without visual changes.

When the user selects the "Create New Account" button, I think it would be best if they were guided through a wizard type progression of windows.

The first window would show available authentication servers, showing the user which servers will authorize their key. Once the user selects next, they are taken to a window asking them for an account name; this account name is checked by the authentication servers to see if it is in prior use before the user can move on. In the third window, the user will be asked to seed the secure random number generator. This window can simply consist of a keypad containing the numbers 0-9, and an "entropy bar" that fills up; this stage is necessary to ensure security of the client key. Once the entropy bar fills up, the next window tells the user that key-generation is in progress, and it will take a few minutes to complete; this window can contain a progress bar and an ETA. Once key-generation is completed, the user will be prompted to enter a password (twice, to confirm); this password will be used to encrypt the private part of the key, and provide a hash for retrieval from the authentication server. In the next (and last) window, the user will see a list of the authentication servers, showing which servers have finished signing the key. Once all of the servers have signed the key, the account is ready to use.

The wizard will close and return the user to the login screen, where the new account will be visible in the drop down list for login. Upon entering the correct password, the client is logged into a new community system.

I've made sure in the back-end design of this system that none of these stages can be broken by the client, another player, a game server, or the authentication server -- provided the client generates enough entropy, and they don't give away their password.

I don't know what the new community system will look like, but implementing a new browser, t-mail, and possibly new IRC chat (or even in-game instant messaging) shouldn't be too difficult once the client verified identity system is in place.

Since this system recreates the entire system used for online play, it isn't restricted to the current system design. But this project is bigger than any one person can handle.

In the third window, the user will be asked to seed the secure random number generator. This window can simply consist of a keypad containing the numbers 0-9, and an "entropy bar" that fills up; this stage is necessary to ensure security of the client key. Once the entropy bar fills up

"Entropy"?
I understand everything else except the meaning of that, but is a Client Key really necessary? Is the Client Key be comparable to a CD key?

It is completely unrelated to a CD key. The client key is a pair of prime numbers (P and Q) that are multiplied together to get the modulus (N), then processed through several complex mathematical operations to get two exponents (E and D), E is public, D is private. P and Q are discarded afterward.

The client's public key thus consists of E and N. The client's private key consists of D and N (they also keep E). This is called the RSA cryptographic system.

Through intensely complex mathematics that would be lost on anyone who hasn't studied number theory or modular number systems, the following actions can be performed:

encryptedMessage = power(message, E) % N
decryptedMessage = power(encryptedMessage, D) % N
This allows ANYONE to send a message to the client that only the AUTHENTIC client can decrypt.

and

signedMessage = power(message, D) % N
message = power(message, E) % N
This allows the client to send anyone a message that is guaranteed to come from the authentic client.

This produces the entire basis for a decentralized mechanism for guaranteeing the authenticity of client, thus preventing impersonations ANYWHERE in the chain.

In order for someone to pretend to be the client, they would need to figure out the numeric value of "D" given only "E" and "N". There are three ways that this could be done: 1) Use the brain power of the NSA, 2) determine P and Q by factoring N, 3) predict P and Q based on weaknesses in the random number generator used to produce P and Q.

The first way is not guaranteed. The cryptographers at the NSA are incredibly sharp, and are probably 10 years ahead of everyone else as far as cryptanalysis, but through reasons that would only make sense to another person well versed in number theory, I doubt even they have cracked this type of encryption system.

The third way can easily occur if the system used to generate random numbers for the primes P and Q is weak and predictable. The purpose of the entropy gathering is to provide "real" random data (the user pushes random buttons, with random time between the button pushes) as part of a seed for a cryptographically secure random number generator, which is then used to generate P and Q.

Provided a large amount of entropy is used for generating the random P and Q values, the only remaining attack is to factor the number "N" back into P and Q. While this is theoretically possible, it is not possible practically when the number "N" is over 300 digits long.

If you had 1,000,000 computers that were capable of 5,000,000,000 division operations per second, you would require 850317600833498040307840245954201
301844201282381557165000225865279
158043510498920395857071167358157
514588524745464615097270033156.5
years to perform such a factorization. The universe would be long gone by the time you were done.

The whole purpose of this system is to make it as resistant to destruction as possible, and as resistant to tampering as possible. With my current design, the authentication servers are used ONLY for creating accounts, and there is zero communication between a game server, and the authentication server to verify the identity of the client.

Thus, even if the authentication server went down, a client with their RSA keypair would still be identified by any game server that has the public RSA key of the authentication server used to sign the client keypair.

The magic of number theory also means that it would be impossible to impersonate a user without their password, which I think everyone would agree is an important part of any user authentication system.

I doubt you would want an authentication system where the person running the authentication server knows your password, and could on a whim pretend to be any user who has registered.