The problem with the way you have it in the example is that it mixes up two different tasks. For example if users wanted to both add, and create new members, they select the checkbox, and then fill in the email. The second task is more complex than the first, and it is not clear in the interface what will happen next. Will they be asked for more information? If the add new action fails, what will happen to the selected member? Will that fail too? What if they want to add more than one member at a time.
The correct approach for this is to separate out the tasks of Select and Add. See example below.
New member is now a sub-task of Add Member.
You may also want to consider whether the overlay is the right way to go, as it is not really correct to allow sub-tasks to happen in overlays.
Classically, the actions in a user interface are: View, Edit, Select, Add, Delete. User interfaces in which all these actions are allowed will generally start with a dashboard that shows a list of entries (members, in this case), and allow sub-tasks to happen from there.
Here are some different approaches that may work, instead of an overlay.
The first approach is a closed loop, where you just allow one action e.g. Add members to list, and then return them to the dashboard. I think this is the one that you want. see example below
The second is a sort of Smorgasbord approach, where you can pick and choose different actions for each entry e.g. select line 3, 6 and 7 for deletion, whilst selecting line 4 & 8 to have their membership put on hold. This only really works if you have a set of closed actions (put membership on hold; delete member; upgrade member etc). You would add a line of checkboxes per action. See example below:
The third option is an open-ended loop, where you start off doing one action e.g. Add members, then make decisions on further actions that you want to do e.g. add multiple members, or maybe, tailor the type of metadata that you want to add for the member/s you are adding.
The second and third options are very useful for complex tasks with expert users, but the first is the simplest and most used for mass users with minimal training and exposure to the interface.