I don't think this is viable. Remember, the AUR was (should continue to be) designed in such a way that it could be run by someone not on the arch server. Direct database access to the main arch repository would be a huge step in the wrong direction for this, in my opinion.
The database servers don't need to be on the same host in order to connect to them. It's possible to make use of the database without losing any modularity on AUR2's part. I was talking with Dan about "standardising" the main site and AUR, mainly in terms of Django models, because the two sites are so similar. AUR could easily simply be a Django app that the main site uses. It's a bit off-topic, but I don't think integrating the sites in some way (at least to be able to duplicate code easily) would be a bad move.
Here's the schema for the package, category and repository relations, in case you'd like more insight into the database structure. As you will see it would be a little difficult to make a record with just the URL pointing to a search on the main site.
{% for dep in pkg.deps %} <a href="http://archlinux.org/packages/search/?q={{ dep }}">{{ dep }}</a><br /> {% endfor %}
or whatever..
The main site search functionality returns the details page if there is a single match. This isn't quite "optimal", as for packages like vim, it will return a list.
A better solution may be to add an additional search argument to the search page, such that 'exact' matches are only attempted instead. eg a seach on vim would only return details on the vim package itself, instead of a list of packages with "vim" in the name.
In order to do it that way we'd need to add another field like "official_deps" to the Packages relation. It would be a foreign key to an official_dependency relation holding only the name of the package (and possibly the url). Not a great solution, but possibly the quickest to implement.