[This answer rescued from this closed Stack Overflow question.]
No. The system process is a special case, but all other processes are run in user mode, even if they are running in SYSTEM context.
Each user-mode process has its own address space. The kernel has a separate address space, accessible only to kernel-mode code. Most threads in a user-mode process run in both user mode (when running code from the process) and kernel mode (when running code from the kernel).
A thread may enter kernel mode as the result of a call to a Windows API function, or because of an external event: when a device driver needs to process an interrupt or DPC, the code runs in the context of whichever thread happens to be active at the time. This avoids the overhead of a context switch, but means that such code has to be able to run in an arbitrary context.
(Kernel-mode code can bypass the security model, but has to be careful not to leak this access out to the user-mode process that it is running in. For example, if kernel-mode code running in the context of an arbitrary thread opens a handle, it has to mark it as a kernel-only handle; otherwise, the user mode process could gain access to it.)
The System process is a special case; its threads run only in kernel mode. This allows device drivers and the kernel to do background processing that is not directly in response to an external event. It is also possible for a device driver to create a kernel-mode thread in a user-mode process.
Although they are still running in user-mode, processes running as SYSTEM are given privileges that are not (in the default configuration) given to processes running in an administrative context. For example, they have SeTcbPrivilege (“act as part of the operating system”) which allows them to do things like using SetTokenInformation to change the Remote Desktop session associated with a security token.