Main problem with using only the password is that you cannot apply salts.
In a normal, robust server which authenticates users by password, the passwords themselves are not stored "as is" but hashed. The password hashing process requires some care, because an attacker obtaining a copy of that file full of hashed passwords (e.g. through a SQL injection attack) can run a dictionary attack: this is "trying" potential passwords. Human users tend to choose passwords which are "words" in some language, or simple derivatives from that (e.g. appending one digit), hence the term "dictionary".
To make the task harder for the attacker, the password hashing process must:
- be inherently slow by mandating, for instance, one million nested hash function invocations;
- be salted: the salt is a parameter which alters the way the hashing works, and each hashed password has its own salt value. This way, when the attacker tries a potential password, he must first choose which hashed password he will target.
The username is the selector for the salt: when the server receives the username, it looks it up in its database, obtaining the hashed password and the salt value which was used to compute that hash (both are stored together). This allows the server to recompute the hash, starting with that salt value and the password which the user provided. If the server gets the same hash value than the one which was stored, the user is authenticated; otherwise, the user is rejected. Good algorithms for that are bcrypt and PBKDF2. I prefer bcrypt (but PBKDF2 is not bad).
Without a username, no salt. The server cannot know what salt value to use for the specific password, hence it must use the same salt (i.e. no salt at all) for all stored passwords. This allows the attackers to attack all passwords at once, which is much more efficient.
It is simpler to see it if you think about an online dictionary attack, where the attacker tries potential passwords on your server. With a username+password, the attacker must send a username and a password, and succeeds if the user with that name indeed has that password. Without the username, the attacker just sends a potential password, and succeeds if any user on the system has that password. If you have 1000 users, you just made the attack 1000 times easier.
Also, when a new user registers, he chooses his password. If that password collides with that of another user, then you have no choice but to reject the registration. At that point, the new user just learned that the password he wanted to use is already a valid password for another user -- you just turned the new user into a successful attacker, and he knows it...
Okay, I must remember not to answer question after eating but before the coffee. I just noticed that your "passwords" are actually UUID with 122 bits of randomly generated entropy. In that case, things will be better. We would not call these UUID "passwords", since they are not "words" and are not chosen by a human either, nor even remembered by a human. These are authentication tokens.
You will still want to do your transactions over SSL. Also, since the customers will not remember them, they will write them down, in files or on paper (more probably files, so that they may cut&paste it -- nobody wants to type whole UUID on a regular basis). This makes the secrecy of these UUID more difficult to maintain. Your clients will have to take responsibility for keeping these values secret; this might be a bit too much to ask of a typical client.