I thought about something like this:

Some thoughts on the difference between username and display name:

usernames are used to identify users. In best case they are all lowercase, match [a-z0-9]{3,15} and can be used anywhere where one can reference a user.

Display names on the other hand, are a UI element in order to make it easier for people to find each other. They shouldn't have too strict limits on characters or length, but the UI doesn't have to show them entirely if they get too long and they should only be used as additional information to the username. If no Display name is set, the username can be used as fallback.

If login provider properties are not allowed to be changed by the user, we could simply have the relation between User and UserLogin be 1-1.
That would most likely yield a startup error if there already is an 1-n relation, when the feature get's activated…

Some example scenarios:

Person A registers its account directly on the instance (currently known as email-register). It chooses a username and a password. With that username and password person A may sign-in at the instance. The display name equals to the username, but may changed in the profile-settings. The profile image equals to the first letter of the username with a random background color. In the profile-settings the person may optionally add an email address to its account to set the profile-image to the libravatar-result of that email address.

Person B uses a social-login like GitHub. After authenticating at GitHub, there will be a prompt for choosing a username. This prompt is pre-filled with the username that the person has at GitHub. Depending on the server-configuration the person may change that username or not. The profile image will default to the profile image from GitHub and the display name will default to the display name from GitHub as well. The user may add an email address to overwrite the image from GitHub with the libravatar-image for the email address.

Person C already has registered on the instance as person A has done it. The next day person C uses another login possibility like OAuth2. After authenticating at the OAuth2 provider, there will be a prompt for choosing a username, pre-filled with the username fetched from the OAuth2 provider. Person C changes that username to the username that was used for registration earlier. By confirming the password for that username, the OAuth2-login and the username-password login are now linked to the same account with the same notes etc.

Re: Person C
I think a cleaner way would be to login with username-based login and in the profile page add an OAuth2 Login to the account instead.

If the login provider provides an image should that be overideable in the non-override mode? I think it's cleaner if nothing can be changed and it could be used by users to identify users.
On the other hand it would be rather dull if the login provider (LDAP) for example does not provide images, but user can't change their profile picture…

The other idea would be to have a dropdown for profile-picture in the profile-settings:

• generated letter on random color
• libravatar image (only selectable if email address is provided)
• external provider (only selectable if account is linked with an external provider like GitHub)

We could actually use {{username}}@example.com for all users without an email address and supply it to the Libravatar function. Could safe us all the hassle with "letter-avatars".

Note: this is more of a backend thought

I think the safe flow for C would be: User C logs in with an existing method, visits the profile-page and presses "add login method", which then goes through the normal flow of selecting a provider, logging in etc. That way, account takeover with an external account that has the same username is not possible.
GitLab handles it that way: https://docs.gitlab.com/ee/integration/omniauth.html#enable-omniauth-for-an-existing-user

We could actually use {{username}}@example.com for all users without an email address and supply it to the Libravatar function. Could safe us all the hassle with "letter-avatars".

I just checked with https://www.libravatar.org/tools/check/ and all example.org mail addresses look the same with default settings. They get unique if we use another style like 'retro'.

Nevertheless, to quickly identify someone I would still prefer a letter on a simple color instead of some pixelart.