Splitting the table to get more clusterization options - will it help? Complete theory.

Let's assume we have a table with a few millions rows. The table has clustered index over PK, and it is important for quick fetching of particular rows. However, the table also has a column kind of CreatedDateTime (non clustered index), and by reasons of report building over particular time span, obviously, it would be great to cluster it too.

Will it help, if I split the table in two - TMain with clustered PK, and TMainTime, with (MainId) as non clustered PK, and (CreatedDateTime) for clustered index? It looks like I can determine the timespan required using TMainTime, searching over its clustered datetime, and then, with MainId values found, fetch them searching over clustered PK in TMain table. Will it ever add something to performance? Or will it eliminate any possible gain by JOIN operation over the two tables?
Since this is a theoretical question I'm sure there will be corner cases where that is a good idea but as a general rule I wouldn't go down that path.

You will, as you state, complicate your regular queries by having to join both tables and you will also complicate your inserts/updates.

A well designed, properly normalized, database with proper indexing on a server that has been sized well should perform adequate with a couple of million rows (and a lot more than that).

For reference, the stack exchange network runs on a mainstream RDBMS and uses no special design tricks. You can verify that for yourself by downloading the database.