The Add() method on navigation properties is the one feature of the Entity Framework not currently supported by DevForce EF. This does not constitute a problem for one-to-many navigation properties, as simply adding the child and setting its foreign key to the appropriate parent will cause it to show up in the parent's list of children.
It is, however, a problem with many-to-many associations where the linking entity has no "payload"; i.e., it has no properties other than the two foreign keys. This is the situation you have. The reason it is a problem is that, as you know, the Entity Framework does not expose the linking entity when it has no payload. You can't add a RelGroup because no such entity exists!
We plan to implement support for Add() in a (soon) forthcoming release. For now your options are these:
Option 1. Expose the linking entity so you have something to add to. The best way to see how to do this is to go through the following process with a scratch model against a simple scratch database:
a. Create a linking entity with a payload column -- anything -- and generate an Entity Data Model from it.
b. Remove the payload column from the table and remove the corresponding property from the conceptual entity.
The linking entity will remain exposed, with only its two foreign key columns. 
Option 2. Add a payload column *permanently* to the linking entity (and update the model). This is the option we recommend, for a couple of reasons. First and foremost, it eliminates the somewhat painful reengineering that you'll have to undertake if you decide downstream that your linking entity really needs a payload (i.e., there's some piece of information you want to track about the association itself). We find that it is a very common occurrence for linking entities to evolve into entities that have importance in their own right and have to carry several pieces of information above and beyond the linking information itself. Secondly, the payload can be an arbitary, single-column foreign key: something we also like. That's probably the kind of key you have for your other entities, and it's nice to have all of your entities operate the same way with respect to the primary key.
FYI, we'll still recommend Option 2 even after we support the Add() method. The Add() functionality won't eliminate the aggravating reengineering involved in adding a payload to a linking entity that started life without one.
 As an aside, we recommend that you *always* make a backup of your EDMX before you do any twiddling of any sort, until you're *very* familiar with the operation you're about to perform. It's easy to get an EDMX hosed up in a way that's difficult to recover from unless you really know your way around.