I don't think that there's a 1-1 mapping between functional requirements and user stories or acceptance criteria.
First, your example of a functional requirement isn't a good requirement. It's not atomic - I would write your functional requirement as multiple requirements:
- The system shall require an email address to create an account.
- The system shall require a password to create an account.
I would then add additional requirements to address uniqueness of email addresses, any kind of password requirements, and perhaps even validation of email addresses. In the end, I would have around 5 or 6 traditional "shall" statements relating to the users creating an account.
As you can tell, there's nothing in these requirements about storing preferences, which is a key aspect of your user story. Looking at your acceptance criteria, you have design decisions codified that aren't part of the user story. There's a disconnect there.
In an agile project that uses user stories, I would create an epic for user accounts and profiles. One story under this account would be creating an account: "As a shopper, I want to create an account with an email address." You may have other stories about logging in with Google or Facebook (or some other SSO) that are part of this epic. Your acceptance criteria would be created to define cases: What should happen when the same email address is used twice? What should happen if a user enters the wrong email address? What happens if something that isn't a valid email address isn't entered?
I would recommend not trying to map concepts from traditional project management methods to agile methods. You tend to do the same types of things, but there isn't a clean 1:1 mapping between things.