I run the YARD project (http://yard.soen.ca) that pimpmaster mentioned above. It's great to see interest in documentation, something Ruby can really use a hand in.
YARD is a project that really does extend far beyond just Rails, since, as some people mentioned, Rails docs are relatively "decent" (I wouldn't go as far as "very good" though) compared to regular Ruby docs.
That said, I'm a Rails developer myself, and improving Rails docs was definitely one of the motivations of this project. A lot of the improvement that you may be seeking (and a lot of other people too), as shadow mentioned, cannot be done with RDoc. Inherited methods, constants, and other such information isn't easily available with current documentation. That's where YARD comes in.
YARD is designed to be extensible from the start. This means that it works great with Ruby DSLs like Rails. It becomes very easy (only a few lines of code under the domain logic) with YARD to give meaning to statements such as "has_many", "belongs_to", "validates_uniqueness_of", or others; this is something that few people have even thought of achieving through Rails documentation improvement because of the current limitations of RDoc. This may not help Rails core documentation too much, but it would aid third party plugin and application level documentation immensely.
YARD also stores all of its parsed data in a 'raw' format; this means that generating XHTML/CSS isn't a necessary step. You can easily take the database that YARD generates and export it to an SQL database for use in an online/interactive webapp that could support user comments, live search, etc. YARD generates HTML with a template framework the same way Rails does (eruby), so this means you can add your own stylesheets/templates and literally change the way documentation displays from top to bottom, making your above mockup perfectly feasible and rather simple with YARD. You're also given a lot more freedom with what information you want to work with.
YARD is fully compatible with RDoc style documentation syntax, but also adds extra functionality to consistently describe argument parameters, required types (when types or duck-types are relevant), exceptions that are raised, and other things. While Yardoc syntax would require *changing* the Rails documentation, hopefully if YARD becomes embraced by the community, everyone will be able to reap the benefits of better, more consistent docs in terms of content, not just presentation.
Anyway, I like your ideas pimpmaster, and your mockup looks nice. I would recommend the following:
* Look into providing more content to documentation pages. Method inheritance might be nice, so would class inheritance trees. Most of the problems with Rails docs aren't based on presentation, but the missing content that it fails to provide; ask yourself if that can be improved in an unintrusive fashion. What methods raise exceptions? In many cases, YARD can provide this information even if the developer did not.
* Is organization by "File" really all that necessary? Most developers don't (and shouldn't) know the internal ActiveRecord/Support/Controller directory/file structures, and probably don't care. Perhaps make it available but in another form.
* I haven't seen your listing of methods, but I would immediately suggest not organizing method names alphabetically, but contextually.. possibly under proper headings. Remember that there are many methods named "new" in the current API docs and that's one of the problems I have in sifting through methods on the current pages.
Anyway, I hope all of this gives you an idea on what my project YARD is about, and what it can bring to the table both for the Rails community and the rest of the Ruby world. Without tooting my own horn too much, I encourage all of you to check out the site and play around with it (I recommend checking the project out from the trunk SVN repo, the gem is a bit out of date) to see what you can do. The site is also a bit out of date, hopefully I will have time to update it soon.