So short answer is yes - using publish/subscribe pattern is very well known model. It helps with decoupling consumers from publishers. Devil is in the implementation details and how much complexity can you handle and what are you willing to trade in your design.
You could start with WCF duplex channel implementation if you are willing to accept it's trade offs (must be WCF client, you own client and service) and limitations (clients directly coupled, network topology limitations).
If the limitations of duplex channel is not to your liking then you can look into using something like MSMQ or NServiceBus to facilitate pub/sub requirements. You can take it to the next level with Windows Azure AppFabric Service Bus.
Duplex can send messages to the client independently not just when call from client arrives.
Duplex is not durable - you got to recover from channel failure when client goes away or there are any communication problems. Securing duplex can be tricky. You have to have WCF client/service on both sides. You have to be aware of your network topology.
You have 2 different bound contexts (systems). One is for the clients to send commands and query and the another one is for publishing interesting events to who ever want's to listen to these events.
EDIT - What if some of the clients are iOS devices ? Would using a DUPLEX pose a problem ? Can you develop an iOS app that communicates to a WCF service via a DUPLEX channel?
Answer: See this SO WCF duplex connection on iPhone? and What should I know when developing interoperable WCF web service?