I would try the following things in this order of difficulty:
Before anything, I would try that 10.19.190.x IP address with the instance name: 10.19.190.x\instance_name, also by servername. I suspect it may be a protocol issue (more on this below), and this may change how it tries to connect.
Second, it simply could be a bug, but since some were cutting and pasting, it may just be a hidden character. I have seen this work for a few people in posts: After you enter the password, move the cursor back to the beginning of the login box, and the hit enter/connect. Are you copying and pasting the pw?
Are there any software firewalls in the way? Temporarily disable them as there may be additional ports in use, which are blocked.
I also have been wondering if one (SQLCMD vs. Studio) is connecting via TCP/IP, and the other by Named Pipes, causing a security failure for one. I would check the SQL Configuration Manager (not the Management Studio) to make sure all the protocols are enabled, and see what is set as the preferred protocol. Enable NamedPipes and TCP, and set Shared Memory to "enabled". I suspect this strongly. Check out this document:
Try unticking the enforce password policy in the properties of the sa user. I also suspect this strongly.
Try running this command from a prompt:
rundll32.exe keymgr.dll, KRShowKeyMgr
If there any entries related to SQL, delete them. Try manually adding a credential for SQL. I have seen things about Vista (so I would assume Windows 7 too) stripping certain security tokens, and I could see this being bypassed at a command line.
I would also try resetting the sa password in SQL, and change it right back. Then if the sa account is being used to start SQL Server, change the password in any SQL Server-related services, and restart them (I am trying to synchronize them to match). Related to this are these commands:
exec sp_password @new = 'sqlpassword', @loginame = 'sa'
alter login sa
with password = 'sqlpassword' unlock,
check_policy = off,
check_expiration = off
Also, have you considered configuring login auditing?
If none of this works, it would be very helpful to see the format you are using for theSQLername to log into the SLQ Manager, and the SQLCMD string you are using. Of course, change anything specific, except it the username is "sa". One more question: One SQL server environment, or multi?
I found some of this here, but weeded through to find only the things that I thought could be relevant: http://blogs.msdn.com/b/sql_protocols/archive/2006/02/21/536201.aspx?PageIndex=7#comments