In the article Choosing Index Keys at SQLServerpedia I found the following lines:
Since data in a table is ordered according to the structure of the clustered index, the index built on last_name, first_name won't behave the same way as the one built on first_name, last_name. The most selective columns should be specified first.
Why? Why should the index on a,b different from that on b,a? Uniqueness of the combination remains same either way, so why should one specify the one which occurs less first?
Uniqueness is the same but the article mentions behavior. Think about a phone book. If you're looking for John Smith it's much easier to find last name = Smith first, then narrow down to first name = John. Try to do it the other way... find all the Johns, then figure out which ones are Smiths?
So, if you are typically searching for people by last name, it would make sense to order the index by last name then first name. This way all the last names that are the same will be on the same set of index pages.
This applies obviously to both unique indexes and non-unique indexes. The uniqueness for index key columns is enforced no matter what the order is. Also keep in mind you don't always need all of the columns to be part of the key - sometimes it is beneficial to just have them as included columns.
I also don't think your index should be unique in this specific case, since it's unlikely that you're going to have the ability to prevent two John Smiths from signing up for your newsletter, or working at your company, or joining your fight club - last/first is not a good key.