I realize this is an old thread, but I found it while investigating partitioning a table. From what I have found, Michael Earl is correct. The fact that you specified the PRIMARY filegroup for your clustered index did indeed move the entire table to the PRIMARY filegroup. It still does partition the data, it just doesn't put the data where you thought it would go. In fact, if you tried to delete the filegroups that were defined in your pratitioning scheme, it would say they were in use; but not because there was data inthem, only because the scheme still references them.

To answer your other question about whether or not a partitioned table should have a clustered index, I think the answer is yes. The answer certainly is that a clustered index is allowed. I found the following in BOL in a section titled "Special Guidelines for Partitioned Indexes":

Partitioning Clustered Indexes

When partitioning a clustered index, the clustering key must contain the partitioning column. When partitioning a nonunique clustered index, and the partitioning column is not explicitly specified in the clustering key, SQL Server adds the partitioning column by default to the list of clustered index keys. If the clustered index is unique, you must explicitly specify that the clustered index key contain the partitioning column.