Is there a way to specify an table/index is sorted by more than one column? Suppose I have a table:

CREATE TABLE [dbo].[TestTable]
(
    [Id] INT NOT NULL PRIMARY KEY CLUSTERED IDENTITY(1,1),
    [Timestamp] DATETIME2(7) NOT NULL DEFAULT (SYSUTCDATETIME()),
    [Data] INT NOT NULL
);


And suppose I need to look up rows by ID (e.g. for joins) and by Timestamp (e.g. for date-range search).

The usual way to do this would be to add an index on Timestamp, but this seems like a massive waste of resources (almost a complete copy of the table) when Timestamp should be in order in the table in the first place. So two questions:


Is there a way to enforce Timestamp being strictly ascending along with Id? (i.e. to make sure pathological cases like changing the server's system clock, leap seconds, Id's Identity-ness being overruled).
Is there a way for SQL Server to make use of the above enforcement and treat the table as indexed on both Id and Timestamp?


I suspect the answer to (1) may be yes, but that (2) is probably a no, rendering (1) a bit useless, but I'm happy to be proven wrong.

Any version of SQL Server acceptable
You can create a clustered index on both id and timestamp columns and even define different sorting order for each column if you want to: 
create unique clustered index idx on TestTable(id asc, [timestamp] asc)
But it won't make much sense in this case for these reasons: 


The engine does not know that timestamp increases along with id, so if you run a query with condition on timestamp, it'll still perform a full scan. 
All additional columns that are included in clustered index will also be included in all non-clustered indexes. 
An older timestamp still could be inserted into the table with newest id. 


So you are gaining nothing and only wasting space when you create a new index and slowing down inserts as timestamp order still will have to be maintained. 

Creating an index only on timestamp column seems like a waste of resources (2 out of three columns of entire table will be included in an index), but actually it's very common for size of all indexes be greater than the size of the table. Slow queries are also wasting a lot of resources, so just create it if it'll boost select queries and if slower inserts will not be a problem. 

To finally answer your question: as you can't implement this logic using indexes and constraints, the only way I see is to create an INSTEAD OF INSERT Trigger. It'll hurt insert performance, but prior to insert you can check if older timestamp already exists in the table and then modify the timestamp, not insert the data, raise an error - up to you.