The SCCM client polling interval is a configurable setting that applies to all clients in the site. Sounds like it's set to 30 minutes at your site but (depending on network limitations/server load) this can be safely changed down to 15 minutes by someone with the appropriate SCCM site access.
There are ways to force a machine to check outside of its normal polling schedule.
There's an open source tool called SCCM Client Center that you can use to connect to a client machine and check/set a lot of the SCCM details with (as long as you have the appropriate permissions).
What you can do is once you've placed a machine in a collection, rather than waiting for it to poll you can connect to it using the Client Centre, select Client Actions -> Download Machine Policy, then wait a minute or two and select Client Actions -> Apply Machine Policy. This forces it to connect to the SCCM server collect any pending policy changes (eg new adverts) and then once they're downloaded you tell it to run them.
Setting a timer on the job running is down to whoever set up the advert for the job in the first place, they had a number of options they can pick for scheduling the job once it's picked up by a machine and presumably in this case picked "As soon as possible". You can also set up Maintenance Windows on machines that set when jobs can/can't be run on them which would stop builds happening in working hours if that's what you want, but it sounds like these parts are outside of your control unfortunately?
I could be mistaking how you're set up but normally once a machine's set up in SCCM you don't need to know it's MAC, and if you ever do you can just find the machine in the console right click it and look at it's details. Adding machines to a collection can be done by machine name, MAC, IP or pretty much any criteria, you only need to know one unique thing about it.
New 'bare metal' builds are obviously slightly different but we don't currently use that part of SCCM (but are planning to move over to it) so I can't tell you much there.
Best Answer
Some notes about the process:
SCCM OSD needs to be setup on one/the sccm server. It's best for the sccm administrator to do this.
An OSD task sequence needs to be created containing the base image and optionally any applications that should be installed at before deployment. A step should be added that joins the machine to the domain as well.
The task sequence should be advertised to All Unknown Computers and All SCCM Workstations. This should be the a non-mandatory advertisement, or you won't like the result. It won't be pretty. I recommend only advertising to PXE clients as well, to prevent it showing up in Software Center, where a user can accidentally upgrade their own computer.
Create an SCCM network pxe point, or if you have an existing wds server you can modify that so that it will boot your sccm boot image, which pulls down task sequences that are advertised to that particular node and gives a choice on which one to install. It can be password protected as well.
With this method, a machine shouldn't have to be deleted from SCCM or AD, though I would also recommend tuning the clean up settings for AD and SCCM both, just for proper maintenance.
I don't recommend that, simply because of the number of times I've seen a computer mysteriously wind up in a collection or container in AD and wondering how it got there.
Lastly, there will be a lot of legwork involved in creating the infrastructure, refining this process, then keeping it up to date. It's best to have a dedicated SCCM administrator for the task, who's sole purpose is SCCM. If you have a sufficient number of clients, however, it is well worth it to automate workstation imaging.