I think that as currently designed, async fn is only intended to be a tool for polling existing Future implementations (from tokio, hyper, etc).
If you want to implement the Future trait yourself by defining what happens when the future is polled and how completion is signalled to the runtime, then you still need to write down the impl Future explicitly.
In addition, note that Rust's async runtimes do not continuously poll the futures. The runtime polls them once, and if they are busy it waits for a readiness notification before polling them again. You can emulate continuous polling by sending such a readiness notification on every poll, but that is likely to be quite inefficient due to the underlying synchronization machinery.
In this particular case, you will probably end up facing the fact that CondVar is fundamentally an async-unfriendly blocking abstraction, and needing to set up a dedicated thread for blocking on it and signalling the async runtime when it does something.
The alternative would be to replace the CondVar with some kind of message queue that sends readiness notifications to the async runtime in a nonblocking way. In the new async design, Waker can play this role.