I'm guessing about the tables, but how about this:

SELECT  COUNT(*)
FROM    clustertrack2 ct2 JOIN accountHistory ah ON ct2.memberID = ah.memberID
WHERE   ct2.AccountLvl = 'Paid' AND
        ct2.LastActiveTime > ah.AccountLvStart AND
        ct2.LastActiveTime < ah.AccountLvEnd AND
        ah.AccountLvStart < getDate() AND
        ah.AccountLvEnd > getDate();

This assumes the accountHistory table gets a new row added every time the account level changes, not overwriting the existing rows.  For example, if user with ID DW12345 goes from free to paid on the 29th September 2009, the AccountLvEnd for DW12345's free record will go from NULL to 29th September 2009.  Then there will be a new record added for DQ12345 for a paid account where the AccountLvStart is 29th September 2009 and the AccountLvEnd is the date at which the paid period expires.  This should restrict a member to one type of account only at any one time.

The three lines:
WHERE   ct2.AccountLvl = 'Paid' AND
        ct2.LastActiveTime > ah.AccountLvStart AND
        ct2.LastActiveTime < ah.AccountLvEnd AND
should be isolate the users that where last active in their paid period, since the last time they were active must fall between the date when they started their paid period and when their pay period ended.

The next two lines:
        ah.AccountLvStart < getDate() AND
        ah.AccountLvEnd > getDate();
would further restrict it so that the paid period falls on the date of when the statistics are taken.  This also assumes that this code is run on the day that you want to gather the statistics.  Otherwise, you can replace getDate() with the date that you intent for the cut-off point.

Actually, are the tables documented anywhere?  Or at least the clustertrack2 and account history tables?  It will be easier if I can know the structure of at least some of the tables.