Deadlock scenario, where is this S lock coming from?
I'll repost my response on twitter here:

Based on the deadlock XML you posted, which lists a trancount of 3 in the session that invokes spUpdateUserAccount, a prior statement or batch in that transaction likely put the lock on IX_Person_TaxPreparer_rowCreated.

I'm presuming this lock is held because of the foreign key constraint in place.

The locks are held for the duration of the transaction, so your second statement can't complete til the first commits the open transaction.