Decoupling the account from the identity allows users to log in to the same account with any identity provider, and have access to all the private resources associated with any external identity within that same account. Think of a storage service that aggregates user data from Dropbox, Google Drive, and OneDrive, and allows you to log in with any one of the 3 OAuth providers to access data from all 3. With a naive model that couples identity to account, this kind of identity federation would be much more difficult to support and extend to additional identity providers.
For those looking to implement support for identity federation in a microservice environment, I'd highly recommend taking a look at Dex from CoreOS: https://github.com/coreos/dex
It provides a consistent OpenID Connect based interface to multiple identity providers and identity management systems, for your backend to interact with (i.e. Dex talks to identity providers using whatever protocols they support, and your backend talks to Dex using OpenID Connect).
In a simple service you can start with just a foreign key from EmailIdentity to the Account. This allows multiple email addresses to be tied to a same account and the same account to have multiple authentication methods or identities (Facebook, email). This way you can implement e.g. changing email address by actually adding an email address and verifying it first, before deactivating the old one.
When you start to need e.g. organization accounts (think about services that have both personal and organizational aspects: Facebook with business pages and ad management, StackOverflow with companies), you can either tie the identities or personal Accounts to the organizational accounts, depending on the model you need.
It can be often useful to add Person model to the mix, which models a real person behind multiple identities / accounts, but this depends on your service.