Thanks everyone for all the responses and good information. I'm sorry I haven't been able to keep up with them. Let me try clarify a few things quickly.
There are 24 columns in this table, there is a unique key field currently with a nonunique nonclustered index. I am changing that to a clustered primary key, as the majority of table access is through that key field. The date field in discussion is not a candidate for the primary key or a clustered index. I was trying to determine if it's worth it to have a nonclustered index on that date field, solely for the purpose of determining the maximum value. A nonclustered index would be just as functional as a clustered index for this purpose. But I was surprised to find that I could do a full table scan on 10 million rows in 1 second.
Here's the context -- the data in that table comes from another system; we just need the current latest value to facilitate updates from the other system. So we don't even need to run the query that often, currently once an hour. In the source system (Oracle) it would be helpful to me if that field was the clustered index, but they need the primary key for their purposes and a nonclustered index I had them add is working fine. A full table scan in that system was horribly slow. Note that this field is a datetime2 in my database, but a date in Oracle, which only goes down to the second.
There are several tables I am looking at. Unfortunately the 300+ million row one doesn't have a unique key -- I was almost able to create one using a composite key of 3 fields, but 3 records violated it. This one will be a little more problematic to update, but since all fields in those 3 records were duplicates it doesn't matter. The max query takes about 30 seconds in that larger table without an index. It would clearly be a lot faster with an index but it would use a lot of space, especially with the composite key.
I'm still amazed these queries are that fast -- it would certainly take a lot longer to return all the data. The plan says 15 bytes per row regardless of the actual size of the row or key, so I'm not exactly sure what's happening, but it appears to be very efficient at pulling just that column.