What you are wanting to do is entirely possible...it's how I load all of my servers : )
The gist of what you want to do, as I understand it, is pass a specific parameter on the boot prompt during the install process (I use pxe and pass them there). You can then capture these parameters during the kickstart process in the %pre section, saving them to a temporary location.
They are then available during the kickstart process itself. After the packages are installed, the "%post --nochroot" portion of the kickstart has access to both file systems: the kickstart RAMdisk and the server's local storage. You can use this section to copy a file containing the variables from your temporary location to the local hdd.
During the "%post" section you can simply source the variable file and use it like any other bash script.
Gabe originally got me started on this process with his blog post here. I have attached a sample kickstart configuration file modeled after his, I did most of it from memory so there may be some syntax or other minor errors, but it should be a good example of how it works. This setup enables me to simply boot a server and provide the identifier and last octect of the IP and after it finishes booting I have a fully functional server that only needs to be added to VI (which I've automated using the perl SDK as well...).
I am in the process (as I get more and more ESXi servers) of using the RCLI and SDK to fully configure the host remotely...the %post section only writes a simple bash script to send the hostname to an XML-RPC service on another server which then triggers it to remotely configure the host according to specifications...this is actually much easier to configure hosts differently because I can use inheritance to group like servers (e.g. all servers in cluster X have these datastores, so the config file for those datastores is simply included for each one), and also because I can duplicate one host's config to another using RCLI / SDK.
There is more information about this type of setup, where the host is remotely configured automatically at startup, here. Some things still must be done on the local ESX (not ESXi) host, like security hardening, installing hardware management/monitoring packages, the fix for NFS snapshots and other similar items (still can't configure AD authentication from RCLI that I know of).
