Update row count on corrupt table
Dealing with the corruption:

First: Any chance you have a good backup from before the page went bad?  If so then you may be able to do a page restore rather than repair data loss.  This would certainly be your best bet.  Remember that in most cases the corruption that caused the error on disk does not affect your transaction logs. So as long as your full backup has a good page then you can restore over the bad page from the full backup, then apply all of the transaction logs (restoring only that single page of course) from that point on.  Of course this only works if you have full recovery.
 https://msdn.microsoft.com/en-us/ms175168.aspx?f=255&amp;MSPPError=-2147217396

Also you might take a look at what was done here: http://stevestedman.com/2015/04/a-weekend-full-of-database-corruption/

If you look at Brent Ozar's answer he used a comparison of the non-clustered index vs the clustered (all of the damage was on the clustered index like I'm guessing yours is if it's a single page) to find the actual damage.  He was also then able to recover the missing information by the same method (clustered index vs non-clustered).

The actual question

You might try using sys.partitions for your counts. They are almost always correct in my experience.  No guarantees given your corruption but it should be good, particularly if you compare multiple indexes.  

SELECT * FROM sys.partitions WHERE object_id = OBJECT_ID('db.schema.table')


If the corruption is in a single page (or if there is no corruption in at least one of the non-clustered indexes) then you will have at least one index where there is no problem and sys.partitions should be correct.  Of course you can also do this to force your count to look at the uncorrupted index.

SELECT COUNT(1) FROM dbo.table WITH (INDEX = [ix_table])