Clustering a heap by date in stead of unique composite key
Non-clustered indexes use the clustered index key value as a pointer back to the data.  If you create a compound clustered index, you are making your non-clustered indexes that much larger.

When choosing a clustered index, especially on tables with hundreds of millions of rows, try to choose a single narrow column if possible.  i.e. choose an integer over a varchar field.  

The Datetime field is 8 bytes with is relatively narrow.  If your data is inserted by date in ascending order (e.g. as time progresses) the records will be inserted at the tail end of the table.  Pages and extents will be added as necessary.

If your data data is spread out all over the place however, you will end up with page splits as new records are shoved in between existing records.  Make sure your incoming date data is accurate.

Be warned that SQL will add an internal 4 byte "uniquifier" to your clustered index if it is not unique.

So, go for the single column clustered index.  Queries that use the datetime column will benefit greatly, and the other indexes will not suffer.