Pretty much what Madhed said.

Basically, once the entity pulls the trigger, he can forget all about what happens next. It really is no concern of the entity what the bullet does. I mean, of course, he cares whether or not he hits something, but once that trigger is pulled there is nothing the entity can do about anything regarding the bullet. So it makes no sense from a realism standpoint to put any sort of delay in the entity itself to handle delaying the bullet.

The bullet should be an entity of its own, governed by physics specific to a bullet entity. Whether or not you actually give it a visual representation in the world is irrelevant (although some bullet types, such as tracers or missiles with a flame trail, really should spawn a visible entity). It can just be a proxy object spawned when the trigger is pulled. This proxy object might set up a timer then go idle until the timer triggers, at which point it performs the raycast and applies the effects of shooting a bullet. Once that is done, the bullet entity self-terminates.

It is a little bit unusual, though, that you are so interested in pursuing realism with this one small aspect of it, while ignoring all the rest of the physics. If a bullet travels at 1000 ft/sec and you are shooting at a guy 30 yards (90 ft) away, and your simulation runs at 1/60 frames per sec, then the delay timer on that bullet fire will be about 5.4 ticks. Not really enough for anyone to notice. But even with the delay, there is a much greater problem with your realism: a raycast doesn't accurately simulate a bullet trajectory. Bullets, even though they travel quickly, are still governed by the law of gravity. Over some distance, the bullet will drop (if fired horizontally) or rise then drop (if fired at an upward angle). At short distances, this ballistic arc is slight and not noticeable, but if using, say, a sniper rifle it becomes significantly more of a factor. Now, you don't really need to mess with it if you don't want; if you want simple aim-and-shoot, without forcing the player to adjust for trajectory, that's fine. But if that is the case, it also seems somewhat silly to account for travel delay, since the player will still have to mentally adjust for movement of the target, so it would make more sense from a realism standpoint to model the trajectory as well.

Maybe this is how modern shooters do it, I really wouldn't know since I don't play them. But it just seems a little odd to me.