I agree with Chris. SQL Server only supports static, range partitioning. So, that the only way to separate values is by range of a certain column.
Having said that, Chris eludes to a larger possibility of "dynamicizing" a static range. He mentions a column with a hash value, but a simple "Partition" column (tinyint) will suit the bill just fine. Then, you can just update that value to move the row between partitions.
CREATE TABLE ArchiveData
Partition TINYINT NOT NULL
And the partition function:
CREATE PARTITION FUNCTION MyPartFunc (TINYINT) AS
RANGE LEFT FOR VALUES (1, 2, 3, 4);
You could write queries that check the number of rows on each partition and "graduate" the rows from one partition to the next, using simple update statements. This could be done as a nightly job.
Also, if you wanted to add partitions, it would be a fairly trivial task to create the filegroup, modify the partition function, and migrate the data to the new partition using update statements.
Having said all of this, I feel I should warn you that this technique is slow. Moving data between partitions is ugly business and if you do go down this path, I would move things slowly to the new partition, due to the huge performance hit that you will take. (The performance is bad enough that Oracle prevents you from updating the partitioning key, by default.)
Also, if you try this, you will want to keep an eye on your indexes and check for fragmentation.