To be honest I think NoSQL would be a bad match here. The eventual consistency traps may be an issue with very frequently updated information and this has problems here.
A better approach IMO would be to start with a standard SQL db (PostgreSQL is a good choice) and do things by logging visits and, asynchronously (separate process in the background) occasionally set counters at roll-forward points. This avoids lock contention.
I doubt your problem is actually a matter of write intensiveness so much as it is lock contention. What's probably happening is that you have several processes trying write to the same counter and only one can be allowed to autoritatively do this at a time. By doing a log, aggregate, and snapshot approach you can avoid this lock contention because the high writes will occur mostly in sequential disk I/O (at least in PostgreSQL).
If I am right and the issue is lock contention I don't really see a viable alternative. You have to have some way of incrementing a counter atomically and you don't want several concurrent attempts to be treated as a single attempt, incrementing by 1.