Here's a small example:

CREATE TABLE t

(x INT NOT NULL UNIQUE,

y INT NOT NULL,

z INT NOT NULL UNIQUE,

CONSTRAINT pkc PRIMARY KEY (x,y));

"pkc" is not the primary key of this table - it's just a constraint. (x,y) is not the primary key either. As Tom already mentioned, in SQL the constraint called "PRIMARY KEY" is a superkey constraint whereas the actual primary key is by definition supposed to be a candidate key and not just any superkey. In this unusual example (x) is defined to be a unique single column and therefore (x,y) is not a candidate key because it isn't irreducibly unique - it isn't the smallest subset of unique attributes of a superkey. Either (x) or (z) could be the primary key of this table, but (x,y) certainly can't be.

So in principle a primary key doesn't have to be the set of columns defined by a PRIMARY KEY constraint. A PRIMARY KEY constraint can be thought of as a technical feature which common sense suggests ought to be used to identify the actual primary key columns, but it doesn't have to be used that way. Once you realise that fact, I think it follows that even in a SQL Server database a primary key doesn't have to require a corresponding index. It is possible (though usually not desirable) to enforce uniqueness in other ways without a specific index: by using a combination of CHECK constraints for example. The primary key of a table might just as well be some column(s) whose uniqueness is enforced without using an index.

Is it sensible that SQL Server creates indexes whenever we use the PRIMARY KEY syntax? Usually it makes sense to do so, but it is also a product limitation. It would be nice to have the option to create uniqueness constraint (PRIMARY KEY or UNIQUE) without SQL Server always creating a new index. Other DBMSs allow that. SQL Server does not.