How to create a 2.x AutoComplete Finder to filter Nodes on those with certain terms

that's exactly what I want too! Dont get it until now. So I subscribe!

What have you tried so far? Can you post an export of your attempted finder as per the guidelines when you create an issue?
Which part is hard - the autocomplete, the "or" bit, the fields?
There is no explanation for these things, the interface is meant to be obvious. It is not a complicated use-case you have suggested, and you certainly seem to have a good grasp of what you want the final result to be. I'd be worried if you spent more than 5 minutes on it.

I created such a finder here:
http://braksator.com/drupal7/term_finder
The taxonomy terms are "fat mothers" and "dumb mothers", pretty much everything else is a node title.

The query is like so:

SELECT DISTINCT 
node.title AS node_title, 
node.nid AS nid, 
node.language AS node_language, 
node.type AS node_type, 
finder_table_1.name AS finder_field_1, 
node.title AS finder_field_2, 
(finder_table_1.name LIKE :finder_keyword_0) AS finder_field_1_matched, 
(node.title LIKE :finder_keyword_1) AS finder_field_2_matched
FROM 
{node} node
LEFT JOIN {taxonomy_index} finder_table_2 ON node.nid = finder_table_2.nid
LEFT JOIN {taxonomy_term_data} finder_table_1 ON finder_table_2.tid = finder_table_1.tid AND finder_table_1.vid = :views_join_condition_0
WHERE 
(
  (((
    (finder_table_1.name LIKE :finder_keyword_0) 
    OR 
    (node.title LIKE :finder_keyword_1)
  )))
  AND
  ( 
    (finder_table_1.name IS NOT NULL) 
    OR 
    (node.title IS NOT NULL) 
  )
)
LIMIT 10 OFFSET 0

I have attached my export of this finder.

At least for me, that's not the problem. I don't get the logic how Finder works in combination with views. I know and understand that the creator of such a massive module can't take the POV of users who take the module from time to time. I used it earlier in drupal 6 and modified it for my needs.
The advantage was the easyness for me because the module was closed. So netbeans or eclipse found the needed code within the module. Now I have to go over 3 modules and don't know where to start.
E.g. I created a new finder, than I took an element (in this case from taxonomy), took the new block on sidebar first.
Result: Nothing, instead I had two instances in the result page (path: views-finder) of my own page.
Then another test by changing your examples (in this case content). Only title was used from you, so I took the field from taxonomy too to enhance my resultlist. But it takes only the title.
Then I realised that you created two views in views. I saw the path of views and compared it with the path of your example. Result: Different. So this was not the point. So I don't know how to tell finder which view is the one to chose!???
And I believe that's what Andrew means.
So at least for me there are two opportunities to proceed. I debug views, ctools and finder until I got an intention of how to use this module or I hope that the inserted db-fields give me a hint of how to use. The most easy way for me would be that you would show in one simple tutorial how to combine the 3 modules to get what we want.
In return I write a documentation of how-to-use, and because I know as a german that my english is improvable, you could override my faults.
Would be happy to come together.
@ Andrew:
If I have mistaken what you want, sorry. But it seems to me that you have the same issues like me.

@#4: The new version of the module is very new, and might change as people find design issues with it. I will try to get a tutorial up by the time I make a full release. Basically you need to know how to configure Views, and you goal is to simply create a View which display all the potential 'results'. You don't have to worry about ctools, that is just needed because of internal functionality to handle the finder settings/objects and the admin page. Tracing how views works is very difficult and time consuming, I have been integrating it into my modules for 3 or 4 years and I still find it very difficult to understand, however it is a very common and powerful module so I think it's worth using - I do wish it would get rewritten and put into Drupal core so more developer eyes and documentation exists for developers wanting to understand it.
I created two Views that come installed with Finder, one that displays all your nodes, and one that display all your users - these are the most basic kinds of View you can have, and I have done a very minimal configuration in them. I also created two basic demo finders, one for nodes, one for users, which use those Views. When you create a Finder, you could use one of the Views I made, but it is also likely you may need to create your own View which limits the potential result set to a particular content type, or a taxonomy term, or something like that.
Previously, in Drupal 6, there was an inbuilt query builder that handled the 'node' and 'user' finders, but it was a bit sucky, very limited fields, and none of the bells and whistles of the query builder in the Views module. One I developed Views integration for finder it became clear that the inbuilt query builder was pointless and had to be removed. An approximation of a 'node' or 'user' finder in Drupal 7 is to use one of the two default Views I have included in Finder.
A Finder works by loading a view and manipulating the database query it does, and also how it outputs the result, based on the Finder's settings and what the user did in the Finder form.
You are not advised to hack the code of the module though, if that's what you meant by using eclipse - this makes it hard to update the module, meaning potential security holes or bugs may remain in your module because you avoid updating. The better option is to create your own module which changes how Finder works, best to leave that for another issue though.

When I type in "dumb mothers" and click "find" it shows a listing of 10 items, which indicates to me that there are 10 items that have the "dumb mothers" term. I would like those 10 items to be displayed when I type in "dumb" (since it should match against the taxonomy_term_data.name field).

If you're saying that you want the node title to appear in the autocomplete suggestion when the taxonomy term matches - there is currently no support for that. The field that appears in the autocomplete suggestion is the field that matches the user's input.
I am aware that people want this feature, and it is the subject of this issue: #1283508: 'Display' field option for choices lists

I also agree with maen that I don't fully understand how Finder integrates/uses the "view" that I assign it. What does it do with the Filters? Exposed Filters? Fields? Contextual Filters? It seems to respect the Sort and the non-exposed Filters, but it seems to override the Fields.

Finder changes the fields, it keeps the existing filters, it does not use contextual filters for it's functionality however you can supply arguments for an existing contextual filter in your view using finder's settings, it attempts to keep the sorting although sorting doesn't work for choices lists all the time so they are resorted through php iirc, the pager is overridden with finder's settings, the exposed filter form functionality conflicts with finder, and the views 'display plugin' and 'style plugin' are replaced although some settings and functionality for those are inherited from what they were set to in your view.

Are you aware the value that is put into the autocomplete textfield will be used in a query to generate the results? The autocomplete does not choose the final result. For me that's a bit of a hurdle, because users are going to have to start thinking differently about that, and configuring it differently.

I can't get my head around this right now, but I doubt it is functionality that could work in a separate module. Part of finder's "finding" process, views integration, results generation, and the autocomplete module need to be changed or we rethink how they work together.

Please use this issue to talk about it: #1283508: 'Display' field option for choices lists

There is also another open issue about improvements to autocomplete functionality, one of the goals of that is to allow autocompletes to silently pass info through to the submit function. That would be a game changer and allow for a lot of features.