A database trigger is an alternative for

Why would you want to do this? What risk does it mitigate?

This sounds like a great way to lock yourself out of your database in a way that requires downtime to recover. Limit your exposure by securing the servers with firewalls and SSH and keep MySQL authentication simple. If you are worried about brute force attacks from within your trusted network, set max_connect_errors to a low value so the remote host will get blocked. And don't use "root" as your root user. Disable that account and create a new super user with a different name.

That device that your friend has was likely built by RSA and is a SecurID tag which uses two-factor authentication to secure workstations. An enormous amount of R&D was built into that product. Your VB script will not have that luxury.

Quite simply, MySQL authentication is not hardened enough to warrant this type of infrastructure. An attacker worth his salt provided with access to an open MySQL port is going to look for more general exploits rather than waste time brute forcing.

Just off the top of my head, some of the problems with this:

What happens if your clocks get off by a minute or two? What if the job or trigger fails? How do you know what state your DB password is in. How do you generate the same random string within your VB script and on the server? How do you store the generated password securely?

Don't do it. Invest your effort into picking strong passwords (not l33tsp34k) and locking down the server itself rather than attempting to reproduce what a company with thousands of employees at their disposal has managed to do.

Short of disabling the trigger before executing your DELETE statement (which would affect all sessions and would only be appropriate if you are doing an off-hours bulk delete), setting a package variable (or defining your own context and setting a context variable) that your trigger reads is likely the cleanest option without reworking the existing application.

When you have an action that generally needs to be done when a row in Y is deleted but not when Y is deleted because of the cascade delete, that is probably not an action that should be in a trigger in the first place. It ought to be part of the stored procedure (or other API) that allows you do do "normal" deletes on Y. Of course, that sort of refactoring may not be possible with a legacy application so you may be stuck with some of the less elegant workarounds.