However, I notice that when a user connects via SSH, another sshd.exe process is created, running under that user account. Does this mean it is OK to have the 'initial' sshd.exe process running as SYSTEM?
Yes, and it's kind of unavoidable – sshd's actual job is inherently highly privileged; after all, it needs to have the privileges to become any user in order to process logons. (And not just by going through the standard Windows process for 'interactive' logons, as that requires the password – SSH keypair authentication can't use that, so it necessarily puts full trust on the sshd service to verify the credentials and then to impersonate your account, which is one of the highest-privileged things a service could do.)
OpenSSH comes from a Unix environment, where the sshd service almost always runs as 'root', an account which has by default even higher privileges than SYSTEM does on Windows. (For example, features like file permission bypass have to be deliberately activated on Windows but are active by default for root on Unix-like systems.) It has been designed to survive in such an environment (see next section), and it'll most likely survive as SYSTEM on Windows.
It is possible to run sshd under a limited account, but that means you're only able to log in to the same account (as sshd is no longer allowed to become someone else) – and it also defeats some of the protections OpenSSH would've had otherwise, since it now exposes that same account to pre-authentication bugs which otherwise would've been confined to the 'sshd' account.
Also, I notice that when a user has connected, but has not yet authenticated (With password auth, will ultimately be disabled on the WAN), an sshd.exe instance is created running under the user sshd_644. Can anyone explain what this user account is?
That's the "privilege separation" mechanism that OpenSSH implements to compensate for its need to run privileged – it doesn't actually let the main, privileged process handle logins; it spawns an unprivileged one which can do very little except talk to the client or communicate results to the parent process. (Linux and BSDs have various mechanisms such as seccomp to limit what the process can do beyond the standard "separate user account" barrier; Windows does too, to some extent, but I don't know if OpenSSH uses them – probably depends a lot on which OpenSSH Windows port you've installed.)
This pattern is commonly seen in Linux services that need to do some privileged things, e.g. a mail server would be started under the root account, but in reality it'd have one overseer process running as root and 3-5 processes handling different tasks under limited accounts (often multiple).
