Although quite familiar with CAN Bus, I'm not very good with cars - I prefer bikes ;). Saying that, have you verified if you can read the speed from the ODB-2 bus? Many cars would have multiple CAN Buses and if you can get the speed from the ODB-2, you might be able to have a node "listening" for it on this Bus and Re-broadcasting it back into the Bus where the cluster is connected to.
You just going to need a dual CAN Bus setup and a MCU to read, probably convert the message, and re-send it. The speed in the ODB2 protocol is very likely to be a different format from the one on the other bus (https://en.wikipedia.org/wiki/OBD-II_PIDs).
In case you car has a single Bus, shared with the ODB2, you should be able to do all of it with a single CAN Bus setup, which waits for the ODB2 speed message, converts it and re-inject into the Bus.
Another option is to create the "speedometer" node from scratch. As you suggested, just build a node capable of reading speed - normally a hall sensor on a rotating axel (like a bike sensor). First make sure you can get the speed right, and print it on a serial monitor - rear wheels might be better. After you have this first part working just need to "encode" the speed back to the format the Mazda cluster is expecting and broadcast it into the Bus.
Whatever you do, just make sure you don't flood the bus with "speed" information, which is probably less important than other ECU messages. Find the minimum rate needed for the Cluster to display the speed and keep like that ;)
Does all of that makes sense?
One more thing, I would suggest to build everything using a micro-controller, but for debugging and building phase, a RPI with a CAN Bus HAT is very handy, capable of easier read and injecting messages on the Bus.