Consider using this query to get a list of dates and the number of registrations on each date.

 SELECT date(registered_timestamp) date, COUNT(*) 
   FROM table
  GROUP BY date(registered_timestamp)

Then an index on table(registered_timestamp) will help a little because it's a covering index.

If you adapt your query to return dates from a limited range, for example.

 SELECT date(registered_timestamp) date, COUNT(*) 
   FROM table
  WHERE registered_timestamp >= CURDATE() - INTERVAL 8 DAY
    AND registered_timestamp < CURDATE() 
  GROUP BY date(registered_timestamp)

the index will help. (This query returns results for the week ending yesterday.) However, the index will not help this query.

 SELECT date(registered_timestamp) date, COUNT(*) 
   FROM table
  WHERE DATE(registered_timestamp) >= CURDATE() - INTERVAL 8 DAY /* slow! */
  GROUP BY date(registered_timestamp)

because the function on the column makes the query unsargeable.

You probably can address this performance issue with a MySQL generated column. This command:

ALTER TABLE `table` 
       ADD registered_date DATE 
       GENERATED ALWAYS AS DATE(registered_timestamp)
       STORED;

Then you can add an index on the generated column

CREATE INDEX regdate ON `table` ( registered_date );

Then you can use that generated (derived) column in your query, and get a lot of help from that index.

 SELECT registered_date, COUNT(*) 
   FROM table
  GROUP BY registered_date;

But beware, creating the generated column and its index will take a while.

select date(registered_timestamp), count(userid) from table group by 1

Would benefit from INDEX(registered_timestamp, userid) but only because such an index is "covering". The query will still need to read every row of the index, and do a filesort.

If userid is the PRIMARY KEY, then this would give you the same answers without bothering to check each userid for being NOT NULL.

select date(registered_timestamp), count(*) from table group by 1

And INDEX(registered_timestamp) would be equivalent to the above suggestion. (This is because InnoDB implicitly tacks on the PK.)

If this query is common, then you could build and maintain a "summary table", which collects the count every night for the day's registrations. Then the query would be a much faster fetch from that smaller table.