Yes, if you have 3 steps in a job then they will execute serially.
It is possible to overwrite variable values contained in a config file at runtime by using the /SET option so you could do this in your batch file command line. I assume you are using a batch file as a wrapper because there are other things in the batch file than just the dtexec command?
If the dtexec command starts to get a little unwieldy then another option is to use a Command File that contains (on separate lines) the various switches and options with which you want to execute the package. Now, you can have as many Command Files as you like, each with different contents so you could call each of your 3 packages and specifiy a different Command File for each package.
There's a article on how to do just that here
Would it be possible to have 3 Execute SQL tasks (one per stored procedure) that are executed in parallel? You could either hardcode the stored proc names or have 3 variables, e.g. @StoredProc1, @StoredProc2, @StoredProc3 reference by each Execute SQL task.
If so then it makes your control file creation at the end of the process a lot easier; you could either do it within a job step immediately after the package execution job step or as a File System process within the package itself. Of course there are other ways of signifying that a completion status such as a Send Email task within the package or by populating a row\column in a table.
If doing everything in one package execution is not possible then I agree that you will need 3 SQL Agent jobs which makes checking for a completion state that much harder. You could have a job step that execute some T-SQL to check a Status column (or columns) in a table on a polling basis by using WAIT FOR - if the Status is NotComplete then wait for a certain amount of time before checking again.
I'll be interested to know what approach you decide to take!
One final note of caution: if your stored procs are querying the same set of tables (at least partially) then you have the potentially for blocking and even deadlocks (assuming you are not using NOLOCK hints or running in READ UNCOMMITED transaction isolation level).