Windows uses a Credential Provider and a SSPI to provide the functionality. The SSPI communicates via web service to the Microsoft endpoints. The endpoints are configured by storing them in a code-signed DLL that gets pushed down via Windows Update. The SSPI will load up the DLL, verify its code signed by Microsoft, and parse out the necessary endpoints.
When the SSPI connects to the endpoints it compares the SSL certificate to a value stored in the configuration DLL. Not sure if its just subject comparison or if they've doing key comparisons, but if the comparison fails for whatever reason the request is rejected.
Further, the process is protected by a client secret. The credentials sent to the endpoint are encrypted using a local secret that the Microsoft endpoints know. Not sure if its a symmetric key or an asymmetric key. Asymmetric key might be more likely though. This key is shared during the bootstrapping process that occurs when you register the computer as Live ID enabled.
For added measure, the way it does SSO into Live-enabled sites is by storing a cookie with a short lived token in it for one of the Live ID domains. Once a user has been authenticated by the SSPI, a request is sent to another web service to get a device token. The service is authenticated by a federated trust to Live ID. If you have a token from Live ID that is issued to your device, you can call this service to get another token. This device token is serialized to some particular format and written to a cookie within the users Windows session. Next time the user browses to a Live ID site the cookie will be present, validated, and you won't be prompted for credentials. There's a bit more to it than this, but that's the gist of the process.
So with regard to spoofing or tampering, Microsoft uses the certificate pinning to prevent MITM, and uses a shared secret to prevent unauthorized clients from making authentication requests.
Edit: If the proper certificate is not in the DLL then the request will fail. An admin could spoof the DLL but they'd need to sign it with Microsoft's code signing keys, and well, bigger issues and all that if they could do that. If the admin acquires the shared key somehow then they could spoof a request using your token, but that means they have to acquire the token some how, which is made significantly more difficult given the certificate pinning. At that point it might just be easier to install a fake Credential Provider and collect the credentials.