Does the sql server compare strings by hash values? If two columns are in the same collation, it would make sense for big strings just to use a hash value in order to compare them and only if they are equal to compare them characterwise. Does the sql server proceed this way?
My guess would be rather not, because that would mean storing hash values that are usable for comparison within the same collation and that would use additional space. However Microsoft states

For single-byte encoding character sets such as Latin, the storage size is n bytes + 2 bytes

which negates the storage of any hash values.
If the query optimizer decides that the execution plan should use a hash join this is exactly what it does. (It can be used in other places too - such as aggregation).
re the quote that you give - I think this relates to a varchar(n) column, so the storage is the number of characters you want to store in bytes plus a 2 byte overhead to manage the variable length.
It´s also quite common to add some sort of hashing or checksum programmatically, for example to represent a long strings checksum using an integer as a computed column, then add an index and search for a checksum match (plus a test to eliminate any false matches caused by a collision).