An interesting question, here is how I would approach this issue (please note, all these steps are theoretical).
NEWAPP, as you describe it, is not a form of a website, but an APP, therefore I will assume you have code execution on the client host and have access to hardware id of the device.
The complexity, and usability will depend on the security involved, and such a design might seem as not overly user friendly. The basic idea is to use hardware id (string unique to each device) as a seed to generating a public+private keypair, and store it on the client device. The verification of identity of the user is performed by signing messages between client and server with a correct key.
There are 3 basic scenarios to usage of such a design:
- User creates an account, and his device generates the key pair and sends off the public key to the server, together with the initial hardware id. The server generates a username by hashing the public key with hardware id as salt. This username is sent to the client and stored locally.
- User adds a new device to the authorized list, and verifies his identity and ownership of the account via a side-channel, be it email, sms, request from in-app. For example, the user enters an email address associated with the account, and receives an email with a unique string generated by the server. The user copies this string into NEWAPP, which identifies him, and a process similar to creating a new account is initiated (the new public key adds a new key, without removing the old one).
- A user logs in from an authorized device, the server and client use PKI to transmit and sign several random messages to verify the identity of the client, and the user is authenticated.
This way, the client would only be able to login once his device is authenticated, and no password would be needed. You could even allow for improved security, and let clients use a passphrase for their key pair.
This design is vulnerable to stealing of hardware id or keys by malware, but that is a whole different story.