How to make a trigger block?

You would need the block to be able to store a custom NBT text tag for the command. Then you'd connect a procedure to the 'entity collides with block' trigger that gets that NBT tag and runs it as a command. (Using the 'get NBT text tag' and 'execute command' functions.) The tricky part will be making an interface that allows you to enter a command into the block, as you'd then also have to keep track of it as an item... one kind of dumb workaround you could try is just using the name of the itemstack as the command for the block. (When the block is placed, you would set its NBT text tag to be the name of the itemstack.)

Making the block invisible is substantially simpler, you just need a blank texture, then set the block's rendering to translucent and its opacity to zero. You'll also want to make sure it has no hitbox and is unbreakable and immovable. 

...All this being said, if you need this to set up triggers for a map, I'm fairly sure there are methods to do this using command blocks. I don't know the specifics, though it could be substantially easier than messing around with NBT tags.

The barrier block, (to the best of my knowledge), functions by using a 'marker' entity with the barrier texture, and spawning these in the block on the client side when an entity in creative mode is nearby. (That's how they can rotate to face the player.) I'm not sure how you would recreate this, but it's also not a great system and can be kind of laggy if you have lots of barriers, visible structure voids, etc. A better (or rather easier) method might be to add a bit onto the block's update code that uses the 'does entity exist in radius' function to check that there is a player nearby, and that the nearest player has the block in their main hand, and, if it finds a player, spawns some sort of static particle effect at the corners of the block. (You could spawn a single particle at each of the block's corners, along the edges, etc.) 

Or you could just make a new block that has a visible texture, and retains the original block's NBT data. When a player is detected, replace the invisible block with the visible one and retain the NBT data. You could also have a seperate update tick procedure for the new block that only reverts it to the original and doesn't run the trigger. (That way you don't accidentally trigger the command while you're building with these.) 

Also, just occured to me you might want to run the trigger code through the player instead of the block. If you check that the block at the player's position is a trigger and then trigger the command if it is, you don't have to worry about triggering the command multiple times if the player collides with, say, a wall of trigger blocks. You could also make a number variable for the player that acts as a cooldown for trigger blocks, counting down each update tick so that triggers don't run multiple times on collision. (If you wanted to get really fancy, you could also save the last command executed as a player-persistent string variable, and check if there's both an active timer and that the new command is identical to the last saved one, so that the cooldown would be specific to each trigger. Or add an additional number NBT tag to the block that determines the amount of cooldown ticks, so you could customize the cooldown time for the trigger blocks.)

Also I rescind my former statement, this is a way better system than command blocks. Good luck!