I would suggest sharing the reasoning for this need right away, to see if others might have a different solution to the problem. The issue being that LANDesk doesn't really have anything to handle performing a package install explicitly at startup. I'm sure with some clever manipulation, one could get it to work, but its not inherent in the UI of the product. Not even local scheduler offers a trigger point for startup. It really only address logon, logoff, lock, unlock, startscreensaver, and stopscreensaver events as triggers, besides IP address change. None of that is probably going to work, otherwise you could theoretically use local scheduler to execute an installation, provided all the files are on the system for the install, and the command line arguments don't get to hairy. Within software distribution settings there is really only stuff for deferral, and the user logoff, but some of these things are being deprecated out. So the simple answer to your question is mostly no.
This might be a bit wonky, but I would suggest you consider a provisioning task, if you can live with push only. Unless they've changed it, there's not a way to run a provisioning task as a policy, but if you can suffer a push only distribution, then provisioning tasks could basically do what you want, as your first command in the task could be to simply reboot the machine, the next step to install your package. This would be as close to startup as you could get. It wouldn't be exactly at startup, but it would be very near it. Then after that, you could have another reboot, or any other chain of events that you want. The only challenge being that your user will not necessarily know what is going on during all of these steps unless you come up with some clever way to give the user some feedback (one example, using autoadmin logon registry values to get the system to automatically logon as a specific admin account, and perhaps produce some kind of text visible in the screen that tells the user that something is happening - a bit of a hack here, good for OS provisioning, but maybe not so great for general packages). Otherwise, the user might well attempt to log on even though your provisioning task is still under way. They would see an interface for the provisioning process though, if they did log on while it was still running, however any reboot commands that you incorporate would take effect without much that the user could do, and only a timer as a warning in that particular provisioning action.
Really you're RunOnce key theory might not be too far off. You could create a basic dos batch package that "installs" registry information for a local GPO startup script, that simply calls that same batch script wherever it is, but pass a parameter in that would indicate that it is running from there. This is a bit of a hack, but it would probably work alright. Your script would have to remove itself upon completion obviously.
Bottom line, where there's a will... It can be pulled off one way or another, but it will probably escape just a simple UI button click to achieve it. First step, apply grease to elbow!
Hope this was at least slightly informative.