First of all I agree with Abhinav, it's quite a lot :).
From the theory point of view, primary key is always unique and not null. Index isn't 'theoretical' part of the primary key. However, all the databases (well, at least the ones that are actually usable) do create an unique index to quickly enforce the uniqueness.
Primary key is also in a different position when it comes to optimization, cursor handling etc. So to answer a bit differently, not having a primary key may lead to performance problems and/or even obstacles when creating the software (depending on the technologies used).
And about the indexes. Index type doesn't matter at all. Clustered is the default type but if you like, you can use non-clustered and actually this would be my decision in certain situations.
[Addition]
When creating a primary key, the DBMS decides how it's implemented (most efficiently). This behavior may change between versions. So when defining the primary key as a constraint, you define the need, not it's implementation. On the other hand if you define how uniqueness is enforced you also define (partly) the implementation.
[Addition]
create table pk_test (
val1 bigint not null
)
set nocount on
declare @counter bigint;
begin
set @counter = 1;
while @counter <= 1000000 begin
insert into pk_test values (@counter, @counter);
set @counter = @counter + 1;
end;
end;
alter table pk_test add constraint uq unique (val1);
select * from pk_test where val1 = 654321;
alter table pk_test add constraint pk primary key nonclustered (val1);
select * from pk_test where val1 = 654321;