Don't get too hung up on the "narrow" aspect of what makes a good index key. Instead of "narrow" think "as narrow as practical." Then, suddenly, your key structure is not at all out of wack. You're only talking about a datetime and an int. That's a 12byte key. It'll be fine. Since your primary access path is through the date field, making this the clustered key is a great idea. You should see very good index seeks to retrieve 40 rows out of 20K rows. And, if you were filtering on date before, you've been likely scanning all 20K rows, so this should be great.

Get an execution plan before you implement the index and store it. Also get some average execution times and reads, all before you implement the index. You don't want to just throw it on there and then not know how well it worked, if it worked. Then you can compare before and after.