In this specific case, there is a unique time to use a nonclustered index that repeats the left side of the clustered index... but you're not at that point.

That case would be when your table is very, very wide (say, near the 5-6k/record mark) and the majority of your queries accessing the table needs only a small handful of small fields (90% of your calls). As an example of a small handful: an ID column and three or four foreign key columns, also of numeric values, and perhaps a date.

Why? These field could be included in a non-clustered index for higher speed access then trying to deal with the full memory set. It's also redundant and puts a load on your insert/update/delete speeds. It's used primarily for speeding up reads on a light transactional system that's either poorly designed or deals with incredibly wide text data that's rarely used (which can also fall under the header of poorly designed, depending on who you ask).

However, you're not there with your example, so don't do that. I just wanted to throw this in there in case you see other designs that may have done it, so you're not suprised.