When we (as7018) were preparing to begin dropping invalid routes received from peers earlier this year, that is exactly the kind of analysis we did. In our case we rolled our own with a two-pass process: we first found all the traffic to/from invalid routes by a bgp community we gave them, then outside of our flow analysis tool we further filtered the traffic for invalid routes which were covered by less-specific not-invalid routes. What remained was the traffic we would lose once invalid routes were dropped. Had the pmacct capability existed at that time, we would have used it.
We (NIST) did a detailed analysis of Invalid routes (with Routeviews data) that was presented at IETF 101: https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin... See slides 10-13. We tried to drill down on Invalid routes which were covered by less-specific not-invalid routes. We examined questions like: how often does the less-specific route have the same origin AS (OAS) as the Invalid, and, if not, then how frequently is the OAS of the less specific route a transit provider of the OAS of the Invalid route? We plan to update the results periodically.
Daniele Iamartino, Cristel Pelsser, Randy Bush. "Measuring BGP Route Origin Registration and Validation," PAM 2015. https://archive.psg.com//141223.route-origin-pam2015.pdf https://ripe69.ripe.net/presentations/103-route-origin-validation.pdf