What's happening here is a little complex, but if you read up on NLA and CredSSP you'll get a better picture.
http://technet.microsoft.com/en-us/library/cc749211%28WS.10%29.aspx
http://en.wikipedia.org/wiki/Network_Level_Authentication
Basically, to answer your question...No, a forged server wouldn't compromise your credentials. First thing they'd have to do to being with would be to spoof your DNS to an incorrect IP, but even then the way RDP works now (assuming we are talking a Win7 or Vista client and a Win2008 or newer server) the credentials are encrypted and not exposed (caveat is NTLM explained in the bottom of the Technet article).
Here's an excerpt that might help from the Technet article:
Unlike the experience in Windows Server® 2003 Terminal Server, the credential prompt is on the client computer and not the server. Most importantly, the client credential prompt is on the secure desktop. Therefore, not even the Terminal Services client can see the credentials, which is an important Common Criteria requirement. Furthermore, the credentials obtained from the prompt will not be delegated until the server identity is authenticated (subject to policy configuration). Finally, the terminal server will not establish a session for the user (which consumes a significant amount of memory and CPU processing time on the server) before authenticating the client, which decreases the chances of successful denial-of-service attacks on the server.
EDIT : let's add an example to clarify...
EXAMPLE #1 - USER HAS ACCESS TO REMOTE SERVER AND USES CORRECT
PASSWORD
In this example, you'll enter the username and password, it will authenticate LOCALLY to the domain to verify it is a valid username/pwd and then try and connect to the remote server. At that point if it is the first connection you will probably get the "The identity of the remote computer cannot be verified" and you can choose to trust it or not.
EXAMPLE #2 - USER HAS ACCESS TO REMOTE SERVER AND USES INCORRECT
PASSWORD
Here you'll see the pic you posted...The credentials did not work. Please enter new credentials. This is done locally on the client (validated against a kerberos ticket or the DC) without ever connecting to the remote server.
EXAMPLE #3 - USER HAS NO ACCESS TO REMOTE SERVER BUT USES A CORRECT
USERNAME AND PASSWORD
Here you'll authenticate locally since it is a valid account and pwd, but once you connect to the server to pass the credentials you'll get:
Hope that helps...