Consider the following composite clustered index:
CREATE UNIQUE CLUSTERED INDEX ix_mytable ON mytable(a, b)
Obviously, a separate index on b will make searching for a particular value of b faster.
However, if a separate index on b is not employed, it seems to me that the composite index can still be used to find tuples with a particular value for b instead of a table scan, by traversing the tree of discrete values of a and do a local search for b, jump to the next value of a, etc.
Is this how SQL Server works? (It would not be, for instance, if MSSQL uses a single hash value for indexes with multiple columns.)
It it is, and the composite index is needed already for other reasons, and the number of discrete values of a is small enough, the performance/space trade-off may swing away from having a separate index for b.
(The UNIQUE and CLUSTERED constraints above aren't really required for this example, but they would represent the fastest retrieval of b that did not involve a separate index for b--the former providing a shortcut for each loop of a, the latter removing one degree of indirection in the lookup).