At the risk of interpreting the original question incorrectly, we  
have had decent success using the Google Search Appliance to  
facilitate search across the enterprise (university):

   * Buy the Appliance.
   * Feed it one or more URLs.
   * Wait for it to crawl.
   * Customize the user interface.
   * Allow people to use it.

While we haven't done so, it would not be too difficult to implement  
a sort of federated search within the Appliance's interface. This  
could be done in a number of ways:

   1. Acquire bibliographic data and
      feed to directly to the Appliance
      via the (poorly) documented SQL
      interface.

   2. Acquire bibliographic data, save
      it as HTML files, and allow the
      Appliance to crawl the HTML.

   3. License access to bibliographic
      making sure it is accessible through
      some sort of API, and write a Google
      OneBox module that queries the data,
      and returns results as a part of a
      normal Google Appliance search.

The larger Google Appliance costs about $30,000 but you purchase it,  
not license it. No annual fees. That will buy you the ability to  
index 500,000 documents. When it comes to a bibliographic database  
(such as a subject index or a library catalog) that is not really  
very much.

We here at Notre Dame did implement Option #3, but it queries the  
local LDAP sever to return names and addresses of people, not  
bibliographic citations. [1, 2] I did write a OneBox module to query  
our catalog, but we haven't implemented it, yet. It will probably  
appear as a part of the library's Search This Site functionality.

In short, I think a Google Appliance is an expensive but viable option.

[1] Search for a name (ex: Hesburgh) at http://search.nd.edu/
[2] OneBox source code - http://tinyurl.com/6ktxot

-- 
Eric Lease Morgan
Hesburgh Libraries, University of Notre Dame