This approach of simply adding the existing actions to the group's _group_actions works fine, at least when it comes catching the error.

It may be difficult to get a useful usage line.  In usage, arguments appear in the order in which they were created, optionals first, positionals after.  Group notation is added if the subset of the arguments appear in its list in the same order.

In the patch .rst, 

    usage: PROG [-h] (--foo | --bar) [--baz]

the foo,bar group is marked correctly; the foo,baz group is not contiguous and is omited.

In bethard's example neither group will be marked
(class TestMutuallyExclusiveGroupWithExistingArguments)

But the problem isn't just with adding existing arguments.

class TestMutuallyExclusiveOptionalsMixed illustrates this with a case where group and parser arguments overlap.

In class TestMutuallyExclusiveOptionalsAndPositionalsMixed, the mix of optionals and positionals makes group marking impossible.

If the groups are in order, but overlap, usage can be a confusing mix

Groups ab, bc, cd, produce: 
    [-a A | [-b B | [-c C | -d D]

But if created in a different order, the usage can be: 
    [-a A | [-b B | -c C] -d D]

So there are 2 issues
   - if groups are not continuous or overlap, what is a meaningful usage?
   - any choice is likely to require a major reworking of the formatting logic.

Since confusing group markings are worse than none, a first step might be to flag a group added via this patch as 'do not mark'.  Also add a note to the documentation that user may need to write their own grouping  instructions (in usage, description or epilog).