The only effect that "with sharing" has is to enforce object sharing rules; that is, if you use "with sharing" and query an object that has private record visibility, any Apex SOQL will only return results for objects shared to them; if you do not use "with sharing", the Apex SOQL will return results for all objects.
As VNE_Hess stated, the user's license restrictions are always enforced no matter what; you can't directly get around them when the code is executing as that user.
It's also worth mentioning that although Apex never enforces field-level and CRUD security, most of the standard VisualForce rendering components do enforce FLS/CRUD, so even though your system-context Apex was able to retrieve (and modify, etc) a field that the user doesn't have profile visibility to, if you pass it to VF via say an inputfield component, the user won't see it.
The Sites Guest User is a special profile that is heavily restricted from making updates to core CRM objects. From memory I think it's read-create only to the core objects except for Articles. Salesforce imposes this restriction AFAICT to require customers to upgrade to more expensive Partner or Customer Portal licenses to get this level of access.
If you're developing AppExchange apps that deal with the standard objects, it's very important to understand that to pass security review, your Apex code must manually enforce FLS and CRUD at every step of the way. This is a HUGE pain in the rear if your app does a lot of these updates, and results in very error-prone code because the ESAPI toolkit that Salesforce provides has a much more error-prone API than the core SOQL/DML interface.
Salesforce would save its app developer community literally thousands of hours of work per year by implementing a "with FLSAndCrud" type keyword, but architecturally that seems unlikely any time soon.
Regardless of what you do, the Account object is not directly editable by external users who haven't been authenticated through the UI. That having been said, there are ways in which you can "authenticate" to your satisfaction to allow users to update a specific field indirectly.
One, would be to use a "form" they submit that is then processed via workflow of some kind or a trigger that updates Account when submitted from your site. The user's email address could be used as an external Id for them along with other information to validate the user has sufficient knowledge of the account to make the change.
Web-to-lead with it's Lead handling Rules can be used to process the form for you and kick off either a trigger or PB to update the Account. You'd also want to use workflow to send a confirmation to the email address of the change which includes a reply link in the template that if clicked, sends a form back to undo the changes made in the update.
The solution I'd recommend would be to have a button that would be clicked to send an email to the account holder's email address that's on record (presumably not displayed in the record), requesting to change their information. If they receive it, they can then follow a link to a form you provide someplace on your site (hidden except by direct link) which they can submit for you to process as previously described.
There are other ways using a custom object as a "mirror" along with a trigger or Process builder/flow that can border on violating the TOS depending on how the information is surfaced. More than anything, it's a matter of how much risk to the integrity of your database that you're willing to accept.
Best Answer
A solution to this problem is to create a custom object with fields that map to fields on the standard object to be updated and give permission to the guest user to update this new object type. Include a reference to the standard object from this 'shadow' object to form a link between the custom and standard records. Create an insert/update trigger on both the custom and standard objects to keep the 2 in-sync so that when the custom is updated it updates the standard record to match.