This is a very good question.  In general, we would be delighted to find a small wiki (i.e., smaller than the En / De / Fr ones) that wants to try this out, and we think that this is realistic.  We think that it would be essential to experiment first on smaller wikis to gain more experience with load, and how to distribute it on the hardware infrastructure, before jumping to the largest wikis.  This is kind of obvious of course.
Note that in any case you can throttle down the load of the extension without affecting the main wiki, as it is all implemented in asynchronous fashion (the main wiki never needs to wait for the extension when serving requests).

Let me now give a somewhat detailed answer on the load.

- When there is an edit, there is an asynchronous job started to analyze the edit.  The key word is asynchronous: it does not slow down the edit http processing on the main server.  Right now, the analysis job is running on the same machine that runs mediawiki; this can change if desired.  The analysis takes a fraction of a second, but requires reading 5-10 revisions from the database, and some other minor db access as well.  So clearly edits become more expensive, but even on the English Wikipedia (5 edits / second at most?) a single CPU would suffice.  As long as edits are a small percentage of the reads (which is true of most wikis), we do not think that the analysis of edits is a significant load.

- When you ask to look at trust information, it is very quick: we just read some alternative markup, rather than the standard one.

- For each revision that is analyzed for trust, mediawiki stores the original, unchanged revision, and we store in an additional database table the same revision, annotated for trust and text origin. If you want to have trust information for all revisions, this causes the db size to exand by a factor of roughly 2.5: not an issue for small wikis, but an issue for very large ones.   In practice, very few people are interested in the trust information for very old article versions, so we could keep the trust information only for the most recent 50 or so revisions (in fact, there is a better way to determine the threshold, but let's simplify).  This would reduce storage, and make it proportional to the number of articles rather than the number of revisions.  It would be quite easy for us to add a variable that enables such pruning; let me add it to our todo list.

- The hard job is when you have a big existing wiki, and you need to analyze all its past, to get the extension up to date.  We are trying to decide whether to build special tools that facilitate this "catch-up" starting from xml dumps; if the WMF expressed clear interest in our extension, we would consider it.  The current implementation can "catch up with the past" at something like 10 revisions / second; to limit db usage, one can throttle this down, e.g. to 4 revisions / second.  This "catch up" analysis can be run in the background, and can use a spare cpu connected to the db, or whatever.  I believe the main bottleneck would be the db load, rather than the cpu load (the cpu load can occur on a separate cpu, the db is shared with the wiki servers).  But if one accepts that the catch-up takes a bit of time, one can just throttle down the analysis; after all, this needs to be done only once for each wiki.

Suggestions and comments are welcome.

Luca