If you enable the ViewStateUserKey, then the server will protect the integrity of the view state by appending a random, unguessable checksum. This checksum acts much like a random CSRF token.
In particular, ViewStateUserKey will compute a Message Authentication Code (MAC) on the view state fields. A MAC is like a keyed checksum of the data, where the key is known only to the server. Because the attacker does not know the key, the attacker cannot generate a valid checksum (MAC digest) for some other value of view state parameters.
If you use a ViewStateUserKey, then the key used is specific to the particular user. This means that a malicious attacker Mandy cannot learn a valid value of the MAC digest for user Bob. Mandy cannot guess it, because a MAC algorithm is designed to prevent guessing the MAC digest. Mandy cannot learn it by contacting to the server, because if she connects to the server, the server will use her cryptographic key, not Bob's key, so the MAC digest that is sent to Mandy will be unrelated to the one used for Bob.
In effect, the MAC digest acts like a random 128-bit string that the attacker cannot guess. This is what prevents CSRF. Standard CSRF defenses involve including a random string in the request parameters (random, so that the attacker cannot predict it). With a ViewStateUserKey, the MAC digest acts as that random string.
See also Microsoft on Securing View State
and Does ASP.NET Viewstate implicitly prevent CSRF attacks? What does this mean for MVC?.