Use Case : Registration of a Team for some event
What you just described can indeed be implemented in various ways but it really depends on how you have architectured your website. Here is how to do it using relation angway:
Use relation module
After installing relation, Create a relation type and name it something like is member of and it's reverse has member. The relation will be from user2user and with arity of 2.
I wouldn't suggest using any other configuration, such as using a single relation from leader to all members. Later it will cause you more pain.

The Membership
I don't know. How does your website work? how does one request to be member of a group? many of these concerns are addressed by OG already.

The registration workflow
Create another relationship registered at relation, from user to the entity type representing the event (the node if it is a node). Use the module rules_link or rules_pane. Create a rules component: register at event that takes two arguments: event node and registering user.
In this component you have to add:

Action: Create a list of any entity type.

name it rel_list.


Action: Add an item to list.

list:rel_list
item:node_event from component arg.


Action: Add an item to list

list:rel_list
item:registering_user from component arg.


Action: Create an entity

of_type:relation
of_bundle:registered_at



From your rules_link or rules_pane call this component and feed it current user and the corresponding node. The created relation entity is an indicator of membership, for leader only!

Add another component: Fetch team members, it's arg: leader user, it will provide: list of users-&gt;members. write a custom rule fetch team members and query all members using EntityFieldQuery or use the module efq_rules to fetch team members. for each queried user, use the above component to create the relation.

you definitely want to have rules_conditional installed.
Central Place for storing memberships.
Instead of a direct relationship from leader to team members you might want to have a node representing the team and create relations from this node to users. this way if you needed to change the leader it can be easily done with removing the is leader of relation and creating a new one to the new leader. But then, having this central entity, why not make it an organic group?
I usually choose relation when I need a fine grained control over memberships.