We explicitly did not support this as we do not support optional dependencies, but we have some reasons for not supporting it.
Consider this: You have package foo which depends on bar OR bar_faux using a provides "Bar" kind of thing. Then you run rosinstall_generator foo --deps, what does rosinstall_generator generate as the dependencies for foo? Does it include bar or bar_faux or both? Presumably bar and bar_faux cannot be installed at the same time, if they can, why not depend on both?
Another similar scenario: You have not released any of the aforementioned packages. You have checked out foo and bar_faux into a src folder. Then you ask rosdep to install dependencies for foo, does it install bar?
These are both example of how this feature would complicate the existing tools, but then there is packaging. This is where it is really problematic, consider: bar and bar_faux provide Bar, and foo depends on Bar, so when you are generating the .deb for foo you can handle that since apt has the mechanism to support it, but what about when you are packaging for Homebrew or Gentoo or anything which doesn't have that mechanism? You now have to look at all release packages and see which ones provide Bar and add them as explicit dependencies.
At that point you have to decide which one of the packages providing Bar should be directly depended on. The only way to do this, that I can imagine, is that one of the packages which "provides" Bar declares itself as the default. But then how do you handle if multiple packages do this or if no packages do this. The later could be because the default one has not been released yet.
By comparison replaces and conflicts can relatively safely be ignored by package managers which do not support it and do not complicate the toolchain significantly.
For the scenario you described, ROS is specifically designed for this case, but you should use multiple packages and a message interface to provide the abstraction not a "provides" mechanism.
You can have a package my_driver_msgs, which contains the interface, then a package which uses my_driver_msgs like my_driver_consumer which can either have a direct dependency on my_driver or my_driver_fake or both. Then your launch files will need to run one or the other. It's more of a composition, you might even have another package like test_my_driver_consumer which depends on my_driver_fake and gazebo or something which has a launch file which launches my_driver_consumer and my_driver_fake together.
Essentially we typically address this OR dependency in CMake or launch files.
With all of that being said, you can modify your debian/control file in the release process to do what ever you want. We're just not willing to support that mechanism across all of our tools and support platforms (current and future).
