As long as the conflict resolver knows that two writers each tried to increment, then it can increment twice. The conflict resolver must know about the semantics of "increment" or "decrement" or "string append" or "binary patch" or whatever other merge strategy you choose. You'll register your "strategy" with Cassandra and it will apply it. Presumably it will also maintain enough context about what you were trying to accomplish to allow the merge strategy plugin to do it properly.
That is to say, my understanding was that vector clocks would be
required but not sufficient for reconciliation of concurrent value

The way I envisioned "eventually consistent counters" working would require something slightly more sophisticated... but not too bad. As incr/decr operations happen on distributed nodes, each node would keep a (vector clock, delta) tuple for that node's local changes. When a client fetched the value of the counter the vector clock deltas and the reconciled count would be combined into a single result. Similarly, when a replication / hinted-handoff / read-repair reconciliation occurred the counts would be merged into a single (vector clock, count) tuple.

Maybe there's a more elegant solution, but that's how I had been thinking about this particular problem.