... how it proves anything about my identity to the webserver?
It does not. It only proves the identity of the server to you so that a man in the middle attack (where someone claims to be google.com) is not possible.
If client identification is required (usually not) client certificates could be used.
"The certificate is intended... Proves your identity" does not mean that the certificate is actually used for this purposes. It only means that the certificate can be used for server authentication ("identity of a remote computer") and for client authentication ("your identity"). But in this case it is only used for server authentication.
Actually "your identity" is in fact confusing because it does not mean your identity at all. What this means is that if you would own this certificate (which you don't) then you could use it as a client certificate to prove your identity. Other certificate viewers (Chrome on Linux) show this Extended Key Usage in a less confusing way:
TLS WWW Server Authentication (OID.126.96.36.199.188.8.131.52.1)
TLS WWW Client Authentication (OID.184.108.40.206.220.127.116.11.2)
Also I'm wondering why there is no "Key Encipherment" or "Key Agreement" purpose for this certificate? Is the 2048 bit RSA key (visible under the details tab) used for encryption?
The certificate I get for google.com with Chrome has no RSA key but is an ECDSA certificate with a 256 bit key. But with some changes to the cipher preferences I can also get the 2048 bit RSA certificate.
According to Which key usages are required by each key exchange method? it needs digitalSignature in the ECDSA certificate and it has this. According to this Q&A it would also need "Key Encipherment" for ciphers like AES128-SHA (which google supports). But the 2048 bit certificate is missing key usage completely so in this case we refer to RFC 5280: 18.104.22.168. Extended Key Usage:
This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension.
Thus if no key usage is given but extended key usage we can imply the key usage from this. And in the same section of the RFC it then states that serverAuth implies digitalSignature, keyEncipherment or keyAgreement. Therefore we have the required keyEncipherment even if it was not explicitely given.
Apart from that neither RSA nor ECDSA keys are used for the encryption of the connection itself, only for authentication and with the ciphers inside the key exchange. Encryption of the traffic is done with symmetric encryption using a key created within the key exchange. See How does SSL/TLS work? for more details.