Both AG and DBM will replicate primarily the log being generated on the principal. The buffer flush rate has some relation to the the log generation rate, but is not identical (think how 100 updates of the same row will generate 100 log records but will only flush the page once, and also think how a single insert could be described in maybe 256 bytes of log, but it dirties an entire page that, when flushed, writes 8kb) and the counters are not per database to start with.
There are some additional control messages and when AG is present there is extra logging, but not significant. I would say that the log itself is about 95% of the traffic. On one hand keep in mind that both DBM and AG can and will compress the log in traffic. But on the other hand DBM and AG will require fully logged operation (minimal logging cannot occur on a AG/DBM source). With AG the number of replicas also plays a role (at worse the traffic gets multiplied x times number of replicas).
You need to consider not only throughput, but also latency. In synchronous mode commits have to be hardened by the replica and this impact the operation latency. Check your current log flush rate in SQL Server, Databases Object.
Once established both DBM and AG have their own counters: SQL Server, Database Mirroring Object and SQL Server, Availability Replica. The raw traffic (including protocol overhead) can be measured also in SQL Server, Broker / DBM Transport Object. Of course, these require to first establish an AG and hit it with load :)
But for an estimate of number of bytes that will be sent (before compression), the log file virtual io stats, as suggested by mrdenny, is a very good aggregate indicator, but unfortunately it gives no information on the actual shape of the throughput (ie. spikes). Unfortunately there is no direct perfmon counter for that.