Technically speaking, It's not impossible; The problem is that it's spammable/DoSable and will need an authority to either allow/deny nodes from inserting to index or someone like our good old friend 'hosts guy' to maintain a list of known good source nodes that people can download and only share the indexes from those.
No authority is needed, because there isn't one already. In the centralized index situation, no human validates torrents uploaded to the centralized indices. Instead, the users do. If you go search for any blockbuster movie you care to name on Pirate Bay, you'll get 50 pages worth of hits. The first 10 to 15 hits might be useful, with various bitrate encodings and various subtitles and audio tracks in them, and then it very very quickly tails off into utter trash. It doesn't seem to hurt Pirate Bay. Nobody ever selects the torrents with zero seeds unless they're looking for something so niche that there's no other option, and no one seeds bogus torrents. Even their pathetic originators give up extremely quickly.
And/Or other simple restrictions like limiting the number of torrents any node can add to the index.
In a decentralized index, that limit is only in the local node, where it is easily removed. Not worth bothering to write the code in the first place.
And/Or a voting system that allows all nodes to vote on others to help the client applications with prioritizing/filtering the index.
The seed count effectively serves as a voting system today. It's by far the most useful metric. About the only other useful metric is a user-defined list of strings. Quality video encodings tend to have some release group tag in the torrent name. Easy enough to push priority up a bit if the user's preferred string is present.
What's missing is implementing support for search within Mainline DHT. Kademlia DHT on which it is based has a scheme already designed:
Filename searches are implemented using keywords. The filename is divided into its constituent words. Each of these keywords is hashed and stored in the network, together with the corresponding filename and file hash. A search involves choosing one of the keywords, contacting the node with an ID closest to that keyword hash, and retrieving the list of filenames that contain the keyword. Since every filename in the list has its hash attached, the chosen file can then be obtained in the normal way.
Mainline DHT has omitted that functionality. If it were implemented, index sites would no longer be required.
Obviously Mainline DHT traffic would increase substantially, but it would still be quite small compared to torrent traffic. Also, if it were implemented exactly as described, clients would be responsible for filtering results coming in from the DHT. Most users want the logical AND of their search terms, but Kademlia specifies a logical OR. Performing that processing is simple enough though, and of course the client could present results much like web search engines do, with results that contain as many of the keywords as possible presented first, followed by results with fewer and fewer matches. You don't get the fuzzy matching most of the web search engines employ doing that, but as it happens, you also don't get fuzzy matching from Pirate Bay search anymore, so that's no loss. Client authors then have the option of preemptively fetching .torrent files in order to get tracker lists to be able to rank the results by how active they are, or of waiting to let users do some manual culling first. That whole process is substantially slower than a centralized index site. Mainline DHT is anything but fast, most of the time. It is, however, bulletproof. As long as the DHT exists, files could be found.
BEP 0005 specifies KRPC methods of ping, find_node, get_peers, and announce_peer. What's needed is a new BEP to extend the protocol, adding search_peers.