OK, I can see customers as being reluctant to create an "account" because
they're afraid it gives the store permission to keep data around for a long time (reality: most data needs to be kept for business/tax/regulatory reasons anyway)
they're afraid that having a "long term" relationship with a store (an account) will mean they're innundated with spam (reality: most mailings should be controlled by explicit opt-in selections that can be revisited at any time)
remembering yet another account name and password is a PITA (using their email address is better than an arbitrary account name they'll forget)
Almost all of the information you would collect for an account is needed anyway for processing an order, so it's not that much more work for the customer the first time around. Giving keys or tokens to a "guest order" to access order status, write reviews, make returns, etc. is a possibility, but the big prize (for customers) is not having to enter everything again, once their email is recognized. You can't keep credit card numbers, etc. without going full PCI-DSS compliant, but does keeping the shipping address, phone number, etc. violate any regulations if access is not password-controlled? An email address is fairly public knowledge, so would it be a security problem to prefill fields based on an email address that the store has seen before? Or should it require a password to retrieve such information? How about allowing access to writing/editing reviews, and checking order status? The confirmation email could have links in it (with tokens) to perform these actions, which could be used as passwords. Or, the customer could create an account at any time (by giving a password), and streamline their interaction that way.
So, the basic checkout interaction could work this way: enter your email first, and if it's known, ask for a password if there is an account. If the customer does not log in with a password, ask for all shipping information. If they do log in, prefill the shipping information, etc. Ask (if they do not have an account) near the end if they'd like to create an account by giving a password. In the confirmation email, give links with long tokens to check order status, enter a review, or create an account with a password (if they did not have an account). If the customer realizes later than they did in fact have an account (or had forgotten their password), and had checked out as a guest, they would need some way to pull that order into their account (another link, if the email is recognized?). It gets more complicated to merge two accounts if they used a second email, or otherwise created another account, but it should be possible.
Would this work, as a normally guest checkout that allows account creation (with a password), and access to various functions via link with token regardless of whether they have (or used) an account? To encourage account creation, what sort of functions or goodies should be available only to those with accounts (cross selling, upselling, "you also viewed", a formal wishlist, prefilled shipping address, etc.)? For "guest" checkouts, what should be the protocol if the shipping address or contact information changes? The email address should receive a copy of the order anyway, plus the changes, just in case something fraudulent is going on.
ask customer to enter their email
not seen before? ->(A)
account for this email?
Yes: ask for password
declines to log in, or gives wrong password? ->(A)
gives correct password within 3 tries
prefill shipping address and contact info
(if customer changes anything, note that in conf. email)
No: no account associated with this email (and repeat customer)
(A) merge point
enter shipping address and contact information
if no account for this email, ask if want to create an account
Yes: enter password twice, store hash in new account entry
ask customer to enter payment information