Keeping in mind the first and last paragraph of Ronaldo's answer, another thing to note is there's just no mechanism in place to add an
IDENTITY to a tabld after the fact. The
IDENTITY column has a couple parameters around it such as the seed and increment value which can even both be negative numbers. An
IDENTITY column doesn't need to be part of the primary key nor does it depend on it.
If one were able to add an
IDENTITY column to a table after the fact, then there would be no way to correlate which rows the
IDENTITY values should belong to. There would need to be additional mechanisms programmed in SQL Server to provide a way to specify how the
IDENTITY can generate the appropriate value for each row, perhaps with an
ORDER BY clause.
But even that doesn't solve every problem, because if the user specifies a non-unique set of fields to
ORDER BY (but wants the
IDENTITY to be unique) then what should the
IDENTITY do?...it could pick one at random like the
ROW_NUMBER() window function does but then it would make the
IDENTITY function non-deterministic which isn't a great characteristic for an
IDENTITY column. Or it could just generate dupe
IDENTITY values and not guarantee uniqueness, which is fine, but doesn't solve the problem of the user.
Long story short, if Microsoft wanted to provide a way to add an
IDENTITY column to a table after it's been populated with rows, it is possible, but it would require a little bit of thought on how it should be done. It also is a feature that isn't very often needed so the current design that restricts the ability to do so is a generally acceptable one.