Since for feature renderers, it is the property page that is registered so that it appears in the UI (renderers themselves are not registered), your best bet is to implement your own property page and relay all (or most) of its calls to an GraduatedColorPropertyPage instance. This class is the property page for class breaks renderers.
Now, for the feature renderer, you have two options.
You implement your own from scratch. You will need to implement most of the interfaces the ClassBreaksRenderer class does as the property page surely relies on them to be implemented.
Again, similarly to the property page, you use composition. Create an instance of
ClassBreaksRenderer and route all calls (on all of its interfaces) except possibly the
Draw method to that inner instance.
It is clear that option 2 is way more convenient.
EDIT: For both classes, you need to pay attention to methods which return GUIDs or create object instances. Those methods are not routed to an inner instance since you need to return a different, correct GUIDs or instances for your classes. This is the case of:
IRendererPropertyPage.ClassID, IRendererPropertyPage.RendererClassID, IPropertyPageContext.CreateCompatibleObject for the property page class.
IPersistStream.GetClassID, IPersist.GetClassID for the renderer.
There is a cleaner way to do that, called COM aggregation. Query interfaces are pointed to the inner instance automatically so that you do not need to implement them on the outer instance (unless you want to override them). Also, COM aggregation ensures that should the author of the inner class add new interfaces in a future release, your outer class will support them as well. Unfortunately COM aggregation can be done only in C++, it's not (as far as I know) possible in .NET runtimes 1.1 or 2.0. There are some new features for custom COM interface querying (which should make COM aggregation possible) in .NET 4, but I have yet to see a working sample.