I prototyped a bit more, and I think, I tackle these design goals:

• Be generic over the timer hardware to be used (e.g. TC0 vs TC1 on Uno)
• Support various CPU-clock rates and resolutions (i.e. interrupt intervals: precision vs overhead)
• Add a macro with which the user "prepares" a hardware timer to be used for time-keeping (i.e. implementing the timer interrupt handle). This way, the HAL doesn't implement the interrupt handlers itself.

My implementation plan so far is to:

• Add a trait (e.g. TimerOps) to avr-hal-generic that abstracts over timers that are usable for this time-keeping purpose
• Implement TimerOps in the respective MCU crates (e.g. atmega_hal) for all eligible timers (e.g. TC0 & TC1 for atmega328p)
• Add a macro to the MCU crates that allows to define the interrupt handler for a specific hardware timer
• Add a trait (e.g. PreparedTimer) to arduino_hal, that wraps a specific hardware timer register type and ensures that the user implemented the respective timer interrupt.
• Also add a macro to arduino_hal to let the user easily create a wrapper struct that implements PreparedTimer for them, including the interrupt handler for the selected hardware timer
• Add a "Clock" wrapper struct in arduino_hal that implements the clock interface (via embedded-time / embedded-hal) based on a value of PreparedTimer

I intend to prepare a PR soon.

I guess this essentially resolves the placing question that I had earlier.
However, naming has become a sort of challenge, especially considering terms such as "Clock" and "Timer", which seem a bit overused.