Yes, essentially you need to do three things to activate a script within a local GPO:

Copy script file into appropriate directory on local system.
Create or modify scripts.ini file to refer to script
Modify gpt.ini file to ensure local GPO is processed
For example, if you need to deploy a startup script to a number of systems, you will need to first copy your script file (e.g. .bat, .vbs or other) to %windir%\system32\GroupPolicy\Machine\Scripts\Startup. Next, you'll need to create or edit the scripts.ini file within the %windir%\system32\GroupPolicy\Machine\Scripts folder. The scripts.ini file holds the name of the scripts that get called, and any command-line parameters that get passed. For example, the following scripts.ini file calls a script called startup.vbs with no parameters.

If you have more than one script to call within the local GPO, then it will follow the first one as follows:

Once you've copied the script and edited the scripts.ini file, you need to ensure that the version of the local GPO is non-zero, and is incremented to account for the new script. This is a bit trickier because the file that holds the version information--called gpt.ini-- will exist already within the local GPO under %windir%\system32\GroupPolicy. You'll need to edit this file, parse the version= line and increment it. If you want to stick with the official incrementing scheme for Group Policy, then you need to increment the version number 1 for each machine-specific change you make (e.g. adding a startup script) and 65536 for each user-specific change (e.g. adding a logon script) you make. For example, if I have a workstation with a GPT.INI file that has a version number of 0, as shown below:

 
Then I'll need to change the value to 1 if I add a startup script, or 65536 if I add a logon script. Once these three changes are made, the script will be enabled on the local GPO for that machine.